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PREFACE 


The Information Operations Team Training (IOTT) and 10 Training Aid (IOTA) project was 
conducted under the Information Warfare Effectiveness (IWE) program, Contract No. FA8650- 
04-D-6405. Program management was provided jointly by Air Force Research Laboratory 
Human Effectiveness Directorate's Warfighter Readiness Research Division (711 th HPW/RHA) 
and the Warfighter Interface Division (711 th HPW/RHC). The current program manager is 1 st Lt. 
Sarah Fockel (711 th HPW/RHAS). The prime contractor is SRA International, Inc.; project 
management is provided by Mr. Steven Schafer. 

The IOTT Mission Essential Competency task was performed by Aptima, Inc. The IOTA, which 
was renamed Influence Operations Training Aid (IFOTA), has been created for use at the 39 th 
Information Operations Schoolhouse in their Introductory Information Operations Integrated 
Course (INTRO 10IC) and their Advanced Information Operations Integrated Course (ADV 
IOIC). IFOTA is designed and developed by SRA International, Inc. 
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Aggressor Squadron, the Information Warfare Flights, the Network Operations Division (NOD), 
the Air Force Computer Emergency Response Team (AFCERT), and INOSC-East organizations 
who participated the MEC workshops. The IOTA team expresses appreciation for the interim 
guidance and support to the IFOTA development effort provided by Major Tim Gameros (711 th 
HPW/RHC) and Major Janelle Viera (711 th HPW/RHA) and Ms Alicia Bledsoe (711 th 
HPW/RHA). Special thanks are also due to 39 th IOS personnel Lt. Col. Thaddeus P. Settlemire, 
Commander, and SSgt James “Spike” Szeredy, who conceived the need for IFOTA and to their 
colleagues Sgt. Michelle DeAngelis, Sgt. Joe Mikos, and Sgt. Charles “Low” Simpson, as well 
as Mr. Russ McLaren (AFOSI) and Mr. Rolf Ludvigsen (SRA), who contributed valuable 
insights from their disciplinary perspectives. 
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1.0 SUMMARY 


The dual Information Operations Team Training (IOTT) and Information Operations Training 
Aid (IOTA) project was a 711th Human Performance Wing, Human Effectiveness Division 
(711 th HPW/RHA)-led effort designed to develop tools for Information Operations (10) training 
support. The IOTT task established a set of 10 practitioner-vetted Mission Essential 
Competencies (MEC), standardization and evaluation techniques for the Information Warfare 
Aggressor Squadron (IWAS) flights and recommendations for generating a MEC-based 
standardization and evaluation task. The IOTA task developed and evaluated the usability and 
usefulness of a prototype rich client Influence Operations Training Aid (IFOTA) for use in the 
39 th Information Operations Schoolhouse’s introductory and advanced 10 planning courses. 
IFOTA, which currently supports psychological operations (PSYOP), military deception (MD), 
operations security (OPSEC), public affairs (PA), and counterintelligence (Cl), provides a 
structured planning environment for developing and deconflicting 10 course of action (COA) 
recommendations and developing associated briefings. 

2.0 INTRODUCTION 

The IOTT and 10 Training Aid IOTA project, Delivery Order 08 under the Information Warfare 
Effectiveness (IWE) task, was conducted by the Air Force Research Laboratory (AFRL) 711 th 
HPW/RHA during the period 25 March 2004 through 24 May 2010. IOTT/IOTA comprised two 
distinct tasks: the establishment of Mission Essential Competencies (MEC) for Information 
Warfare Flights and the development of the Information Operations Training Aid (IOTA). The 
MEC effort was accomplished by Aptima, Inc. under the direction of prime contractor SRA, 
International, Inc.. The earliest phase of the IOTA effort was initiated by Metrica, Inc.; the effort 
was then transitioned to SRA International, Inc., which became solely responsible for its 
completion. The IOTT/IOTA project’s purpose was to conduct and support research and 
development activities to improve the overall effectiveness of Information Warfare (IW) 
operations. This report discusses the accomplishment of the IOTT/IOTA project. 


2.1 Task One: Mission Essential Competencies (MECs) 

The IOTT MEC effort objectives were to apply the 711 th HPW RHA MEC methodology to: 

1) define competency-based training requirements, 2) identify competency “gaps” in operational 
training, and 3) identify training methods, tools, and performance measurement criteria for 
individual, flight, and squadron level combat mission readiness. Task One employed a functional 
work analysis of three AF IWAS flights to identify cognitive components of the MEC construct 
(including the MECs, supporting competencies, knowledge, skills, and developmental 
experiences) and to analyze and evaluate training gap impact. Data collections were 
accomplished in two workshops at each of the following: the IWAS, select Information Warfare 
Flights (IWFs) within the Air Operations Center (AOC), the Network Operations Division 
(NOD), the Air Force Computer Emergency Response Team (AFCERT), and Integrated 
Network Operations and Security Center (INOSC)-East organizations. 

The initial workshop tentatively identified MECs; the second workshop obtained feedback and 
refined the initial collection. Specific focus was placed on identifying interconnections among 
knowledge requirements, knowledge development, and information/knowledge exchange for the 
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organizations studied and their higher headquarters, customers, and supporting organizations. 
Task One products included the following: 1) a recommended approach to bridge information 
exchange gaps among 10 units, 2) a set of standardization and evaluation techniques for the 
IWAS flights, and 3) recommendations for generating a MEC-based standardization and 
evaluation task. The interim and summary reports on conduct and results of the IOTT MEC 
project were delivered to the government for publication separately from this report. 


2.2 Task Two: Information Operations Training Aid (IOTA) 

The objective of Task Two, the IOTA effort, was to integrate, demonstrate, and transition 
advanced training and rehearsal technologies to facilitate successful integrated combat operations 
for 10 Warfighters. The effort was to provide science and leading edge technology to develop 
and demonstrate an innovative training aid for Influence Operations (IFO), called IFOTA. The 
effort included transition of an existing customer-mandated planning capability into a training 
aid to expedite, enhance, and enrich the training of inexperienced Influence Operations trainees 
in the successful planning and integration of IFO campaigns. The effort was envisioned in two 
parts. The first part encompassed the development of prototype software modules and supporting 
documentation, scenarios, and training materials. Proof of concept was demonstrated through 
testing in a simulated classroom exercise. The second part focused on an empirically based 
evaluation and assessment of the prototype software’s usability and usefulness. Task Two 
products delivered to the government were the IFOTA software and software training, a user’s 
manual, and a formal evaluation of the usability and usefulness of the IFOTA software. During 
the course of the effort, the IFOTA software task was updated to incorporate a new module, a 
change in platform and the addition of several functions. In consequence, the IFOTA software 
deliveries were incremental; the final iteration was IFOTA version 4.0, an Eclipse-based rich 
client platform (RCP) with both student and instructor modes and five IFO planning modules: 
PSYOP, MD, OPSEC, PA and CL IFOTA 4.0 incorporated both tree and Gantt-style timeline 
views of the integrated, effects-based 10 plan, which associated tasks with objectives and 
measures of merit and a filterable, map-aided scenario selection interface. 



Figure 1. IFOTA opening interface and example plan tree view 
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The primary stakeholder for the IOTA effort was the 39 th Information Operations Squadron (39 th 
IOS) at Hurlburt Air Force Base in Florida. The 39 th IOS is U.S. Air Force's premier Information 
Operations and Cyber Formal Training Unit. Four courses are taught there: 1) the Information 
Operations Integration Course (IOIC), 2) the Signature Management Course (military deception 
and operations security for wing level SMC officers), 3) a military deception course for 
operational level planners, and 4) the Undergraduate Network Warfare Training course. 10 and 
Cyber schoolhouse classrooms are equipped with cutting edge communication and computer 
systems, including secure video teleconferencing and fiber optic infrastructures; software 
applications include the Information Warfare Planning Capability (IWPC). The schoolhouse is 
designed to support real-time war gaming and instruction at multiple security levels. 

The IFOTA tool was initially designed to meet IFO training support needs expressed by the 
instructors for the IOIC, required training for Airmen assigned to 10 flight billets; IFOTA was 
intended to promote guided discovery within scenario based training, to accustom students to 
work within the conceptual framework of the 10 portion of the Joint Air Operations Plan 
(JAOP). It was also to serve as a test environment for the course capstone exercise, a role- 
playing effort in which students work within a scenario to plan and submit the 10 portion of the 
JAOP. Promoting in depth preplanning analysis, IFOTA was envisioned as an adjunct to rather 
than a replacement for the current 10 planning program of record, IWPC. [Note: Although the 
IOTA project was initially conceived to eventually encompass the full range of Information 
Operations, the project was descoped to focus on IFO training.] 


2.3 IOTT/IOTA Accomplishments 

The IOTT/IOTA project produced both Information Operations training guidance and a 
prototype tool for instructional and refresher use at the 39 th IOS and at the IWFs. The project 
built upon prior work by Aptima, Inc., in MEC definition, and leading edge software design 
approaches being developed by SRA International, Inc. It also drew from guidance created by 
the IWF and planning communities (e.g., handbooks, exercise materials, training briefings), and 
to some extent, from published work done by Metrica, Inc., for AFRL that had begun to break 
down 10 tasks. The products have been successfully shared with the operational community. The 
IOTA product, the IFOTA tool, was demonstrated at the 2007 JFCOM Information Operations 
Planning Capability-Joint (IOPC-J) Warfighter Analysis Workshop, the 2008 Air Combat 
Command Warfighter Analysis of Innovative Technologies and Concepts (WAIT-C) interactive 
technology demonstration and at the 2006 and 2007 Phoenix Challenges, where it received 
enthusiastic response from 10 professionals. In addition, the structured planning and analysis 
framework IFOTA offers drew praise from a range of AOC planners, who found its 
methodology readily generalizable to strategic and operational planning. 

The body of this report describes the data collection (knowledge elicitation) and design plan, 
encompassing the work domain analysis (including training gap analysis), work-centered design 
approach (including usability and utility testing), and proof of concept for the IOTA project. The 
IOTT MEC report, as noted earlier, was delivered to the government separately and may be 
requested through the government project manager. 
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3.0 APPROACH 

Knowledge elicitation for the IOTA task was accomplished at the 39 th IOS at Hurlburt Air Force 
Base, FL. A joint Cognitive Systems Engineering and Systems Engineering (CSE/SE) team of 
design specialists made two trips to collect information on site. Feedback on collected 
information and requirements analysis was accomplished via teleconference. 

3.1 Cognitive Work Analysis 

During the course of the IOTA effort, cognitive task analysis laid the foundation for the IFOTA 
design work. The design team employed cognitive task analysis (CTA) to elicit, document, and 
evaluate information about the work domain and the users’ work-centered requirements. CTA is 
an integrated set of methods and tools for uncovering both the cognitive processes that control 
task performance and cognitive capabilities employed in task performance. Over the course of 
the IFOTA task effort, the design team evolved its CTA philosophy and methodology to refine 
its processes and incorporate lessons learned in how to successfully translate CSE products into 
design requirements that can be readily understood and used by the SE development team. A 
foundational concept for CTA development is that insertion of an aiding tool effectively changes 
the work environment, and therefore, business processes, opening opportunities for business 
process redesign (BPR). The IFOTA team integrated several Unified Modeling Fanguage (UMF) 
modeling techniques to enhance the usefulness of their elicitation opportunities and improve 
communication between cognitive systems and software engineers. There are four elements of 
the IFOTA CTA process that bear mention: 

• Modeling of human-to-human, human-to-system, and system-to-system workflows to 
capture the current work environment and support redesign analyses. 

• Frequent user validation and course correction, incorporated into an iterative design 
process, is emphasized. Users get a chance to see how their inputs are interpreted in 
prototype designs and to ensure both that what was heard was what was said and that new 
ideas sparked by the design evolution are captured for the next iteration. 

• Requirements traceability is maintained, specifying sources including underlying doctrine 
and command direction as well as situational constraints and restraints and insights from 
individual experience. 

• Context is maintained through the organized presentation of requirements in terms of the 
situationally defined work functions they support. 

To serve the customer, the aiding system end user, the design team conducts unstructured 
interviews, employing elements of several CTA methods for elicitation. After extensive domain 
research, a joint CSE/SE team approaches the user in the user’s workspace; the team conducts 
cognitive walk-throughs of both typical and atypical work days to capture the range of work 
activities in context of variable workload conditions. The team examines critical incidents for 
cause and effect relationships (Flanagan, 1954) that extend its understanding of the work 
environment. The team also conducts field observations and collects example work artifacts 
(Eggleston, 2003 ). The team then transforms raw notes into concept maps (Moon, 2004); for an 
example, see Figure 2. Other initial artifacts include product-focused procedural task diagrams 
(Militello & Hutton, 1998) and communications diagrams (Moon, 2004) to capture work 
structure. The IFOTA CSE/SE analysis lays out operational and system requirements, 
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maintaining traceability, and employs use cases and other SE documentation methods to ensure 
system function meets operational needs (Zhou & Burns, 2004). 


Capstone Exercise 



which are 


Communications 



Figure 2. Concept map of Capstone Exercise from IOIC instructor interview. 
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3.1.1 Applied Cognitive Task Analysis (ACTA) 

The CTA method employed is a modified form of the Applied Cognitive Task Analysis (ACTA) 
method developed by Klein Associates. The ACTA method (Militello & Hutton, 1998) employs 
verbal protocols to elicit work domain knowledge. According to Militello and Hutton, ACTA 
provides streamlined CTA methods developed for training practitioners and systems designers to 
elicit and represent cognitive components of skilled task performance, and the means to 
transform those data into design recommendations (p. 1619). Developed under a Navy project, 
the complementary elements of the ACTA elicitation method include: 

• Task Diagram Interviews (scoping the task, building a roadmap of goal-oriented process) 

• Knowledge Audits (determining what operators must know to successfully complete 
tasks, capturing work patterns through structured interviews) 

• Simulation Interviews (capturing decision points, judgments, and work-arounds through 
generative interviews, expanding and refining the decision criteria for task 
accomplishment) 

The IFOTA design team used task diagramming interviews, abbreviated knowledge audits and 
focused simulation interviews to draw requirements from the operational community. The 
information obtained was represented in concept maps and task diagrams (Figures 2 and 3), in 
which the capstone exercise and Counterintelligence planning process were mapped. In concert 
with the above techniques, the design team documented field observations in order to capture the 
realities of work activities in the work environment. 

Analysis of the information collected during the knowledge elicitation phase is supported by 
multiple methods. Process flow charts, Integrated Definition for Function Modeling (IDEFO), 
event sequence analysis, and sequence diagrams are familiar methods to display the march of 
events, decision points, and feedback loops of the tasks under investigation. The linear 
appearance of the process flow and IDEFO methods have been criticized in the past for obscuring 
the complexity of the event sequence (Figure 3). Concept mapping, although traditionally used to 
graphically convey information in the form of statements, is sufficiently flexible to permit the 
investigator to lay out information to suit the needs of the analysis. 

3.1.2 Work-Centered Design (WCD). 

The guiding principles for the IFOTA CTA were found in AFRL’s work-centered support 
system method, which was developed to support work-centered design, a methodology that 
emphasizes work as a dynamic process comprising problem solving/decision making, 
collaboration, product development, and work management, each of which must be explicitly 
addressed in the design process (Eggleston, 2003). 

The IFOTA task developed a contextually based perspective on the work-centered design 
concept and our focused application of several CTA knowledge acquisition capture and analysis 
strategies was modified to directly support software design. 
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Figure 3. Counterintelligence process flow ( based on interviews with Cl subject matter experts) 

3.1.3 CTA Artifacts, WCD and Software Requirements Specification 

The context of work-centered aiding system design is business process reengineering (BPR)— 
the insertion of an aiding system changes the business process. Therefore, the CSE/SE team 
approaches each collection effort as an opportunity to document and analyze the current and 
projected business process. This perspective suggests a number of commonly accepted systems 
engineering methods to document analysis in a format that is readily understood and used by 
CSE/SE staff. 

The software design information that is captured through CTA is initially embedded in CSE 
artifacts. However, once environmental constraints, task sequences, information exchanges, 
decision requirements, task goals and products are identified, the information can be represented 
in standard SE decompositions, such as flow charts (e.g., cross-functional flow charts, process 
and information flows) and UML diagrams (e.g., sequence diagrams, use cases). This serves two 
important functions: 1) it permits the CSE staff to control the translation of design guidance into 
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design specification and 2) it provides uninterrupted traceability from data collection to design 
requirements and design execution. Figure 4 illustrates CSE/SE translation. 



3.2 IFOTA Knowledge Elicitation 

The IFOTA knowledge elicitation was conducted over the course of two trips to the 39 th IOS and 
was supplemented by e-mail and teleconference. The first trip laid the groundwork for the 
training support effort. Instructors explained course objectives and measures of merit and 
provided student handbooks, supplementary literature (e.g., AF doctrine documents), sample 
course curricula, and course briefings. The 39 th IOS instructors conducted tours of the facility 
and described typical class activities. Instructors noted the range of student expertise and the 
need to challenge class members according to capability. The second trip demonstrated a web- 
based version of the IFOTA concept provided by subcontractor Metrica, Inc. The demonstration 
and evaluation of the browser-based tool held on-site with the 39 th IOS sparked further 
requirements specifications that led to the transition of IFOTA from a web-enabled form-based 
version to a fat client application with more design flexibility and more capability. 

4.0 RESULTS AND DISCUSSION 

4.1 Knowledge Elicitation Trip 1 

The initial knowledge elicitation trip was hosted by the 10IC instructors at their 39 th IOS facility 
on Hurlburt AFB. Interviews were arranged with PSYOP, MD, PA, and OPSEC representatives. 
As the tool to be developed was to be jointly evaluated on utility and usefulness, the data 
collection was organized around these two themes. 

At the time of the knowledge elicitation, the 10IC was transitioning from a ten-week to a six- 
week initial qualification training course designed to train 10 planners assigned to IWFs. The 
course focused on the fundamental knowledge required to leverage 10 within air operations 
planning. It taught the basics of 10, Air Force and Joint doctrine, executing organizations and 
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operational functions through lectures, seminars, participatory planning activities and a capstone 
exercise in which student teams planned an integrated 10 campaign. At the time data collection 
was initiated, the curriculum also included introduction to the Joint Air Operations Center 
(JAOC) and Joint Air Operations Planning, air warfare employment and concepts, fundamentals 
of 10 disciplines, and 10 integration into deployed air power structure and processes. 

While students represented a breadth of rank and career fields, the majority were either currently 
assigned or will receive assignment to slots within the AOCs. Classes of approximately 20 
students were split into four teams and practiced interpreting planning guidance, assessing 
situations and developing and deconflicting 10 planning recommendations in support of the Joint 
Force Air Component Commander (JFACC). Emphasis was placed not only on leveraging 10 
targeting options but also on plan integration (integrating 10 methods to achieve an objective or 
objectives) and on plan deconfliction (resolving potential conflicts among component planning 
efforts). Several points were raised that were overarching design influences. The first two issues 
regarded fostering good planning skills: 1) promoting identification of task terminators and 
effectiveness metrics, and 2) promoting probabilistic thinking (i.e., forecasting probability of 
success) and exploratory excursions in support of forecasting. The third issue involved ensuring 
ability to teach to individual capabilities, challenging a range of student expertise. 

The desired system, as described by instructors, would allow students to conduct structured, 
collaborative, integrated 10 planning—from the identification of operational and tactical 
objectives and tactical tasks (with associated success indicators and measures of merit) through 
the development of proposed task actions and support requirements. Instructors expressed a 
teaching for mastery objective. Their ideal system would permit instructor-supervised students to 
build a complete proposed plan and would also capture student rationales, supporting 
documentation, instructor comments, and deconfliction actions. It would support forecasting 
activities such as “What if,” sensitivity, and impact analyses. Initial requests considered a 
feedback function that would identify missteps as they were made and display a comparison of 
“right path” vs. “wrong path” cascading effects. The system would support in-class instruction, 
practice exercises, and testing. 

The baseline system concept and tasking was derived from a PSYOP planning tool (PSYOP PT) 
developed by Metrica—a browser-based tool with several PSYOP scenarios (e.g., refugee 
repatriation, insurgency support, population protest, force surrender) and a subjective rating 
method for calculating anticipated change resistance. The 10 methods shared a common focus on 
identification of target audience (TA) and employment of behavioral shaping methods. 
Methodologies, however, were discipline-specific and required considerable adjustment of and 
extension to the Metrica PSYOP trainer capabilities. The PSYOP method assessed current vs. 
desired TA attitudes to find a behavioral shaping difficulty index; command guidance provided 
themes and messages. OPSEC employed its own risk assessment methodology. OPSEC was 
noted as having highest potential for inter-discipline conflict, as the other disciplines typically 
exploited friendly activity indicators, whereas OPSEC was focused on obscuring those 
indicators. MD methods, focused on redirection of adversary attention and perception control, 
were highly integrative and frequently required coordination with and active cooperation of sister 
services as well as other 10 disciplines. Student efforts were to be guided, step-by-step, through 
each discipline’s process. Specific discipline references provided means as well as methodology. 
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Students were to cite both applicable doctrine and the intelligence information used to support 
their strategies. Developing student attention to the relationship between objectives/tasks and 
measures of merit (e.g., measures of effectiveness and measures of performance), as well as the 
identification of termination criteria, were to be emphasized. 

The ongoing documentation of the complete student planning effort would allow the instructor to 
correct errors and respond to student queries on the fly, understand underlying student thought 
processes, and check references for appropriateness. Excellent plans would be archived for future 
use in instructional scenarios. Instructors and permitted students would create and archive whole 
and partial 10 example plans for use in classroom instruction. Desired planning visualizations 
included a map-based view for archived plan selection and a holistic hierarchical plan view. 
Instructors would manage student log-ins and permissions, plan archives and student records. 
Reachback simulation was considered very important. The system, as initially envisioned, would 
require a browser capability, connections to Secret Internet Routing Protocol Network 
(SIPRNET) and Joint Worldwide Intelligence Communications System (JWICS) as well as to- 
be-determined databases (e.g., Sensor Harvest), local area network access (server-based 
archives), a recorded instant messaging, and possibly, chat capability, shared document access 
and editing management. Figures 5 and 6 illustrate the intended system use, as understood from 
the initial data collection. Forecasting and feedback functions, while discussed in the idealized 
system description, were not incorporated at this time. 


Student Activities 



Students 


Figure 5. Planned Student Activities within IFOTA as initially described. 


10 

Approved for public release; distribution unlimited. 





























Instructor Activities 



Figure 6. Planned Instructor Activities within IFOTA as initially described. 


As shown above, the knowledge elicitation drew forth an idealized system description that was 
identified as a goal to work toward in a spiral design model. Initial funding for the system 
covered the basic design of a student module supporting four disciplines (PSYOP, MD, OPSEC, 
and PA), a searchable plan archive and the instructor module for managing student log-ins. The 
next iteration incorporated a Cl component, undo/redo functions, a clickable map view for plan 
selection, and extended the instructor module to capture student grades. The next iteration 
provided a spell check function and Gantt chart plan timeline display. Neither the feedback 
function nor the exploratory excursion or probability of success algorithms were funded. 

The following section presents an example of the discussion points that the elicitation raised. A 
list of derived system requirements follows. 

4.1.1 Elicitation Findings/Discussion Points for Usefulness (Focus on the Task) 

Job Requirements 

1. Mission-level Expectations: 

a. Students will be taking the role of AOC staff and will have to consider how their 
input factors into the overall mission plan 

Issue: None currently identified 

b. Students will take roles of PSYOP, PA, OPSEC, and MD planners. Their plans 
should show synergistic effect of integrated 10 plan. 

Issue: Links (especially dependencies) among plan elements must be manifest. Timing 
considerations must be clear; temporal impossibilities should raise flags. 

c. Expectations are that students will push to have the training tool made operational. 
Issue: The more realistic the training tool is, the more likely students are to push for it; 
a very realistic training tool will be easier to operationalize. However, the train as you 
fight concept may become an issue, unless this tool is adopted into a system of record. 

d. The students must integrate and deconflict their recommendations with other 10 
disciplines 

Issue: A vision of how the deconfliction aspect will work has not yet been articulated. 
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Trainer Tool Use 

1. Tracking: 

a. Trainers have not yet considered all they want the tool to track. They exhibited a 
positive response to the suggestion that the tool might include a mechanism for 
tracking exercise and test performance. System tracking would lighten the trainer 
workload. 

Issue : Any tracking expectations should be worked out now to aid the designers’ 
planning process. Trainers indicate they will be giving individual grades and group 
grades for group efforts. How to track that should be thought out in advance as well. 

2. Testing: 

a. Trainers expect to use the tool in both in class exercises (partial tasks) and the 
capstone exercise that will permit students to integrate all they have learned in the 
course. 

Issue: Trainers indicated a desire to be able to see what students were doing in order to 
supervise and aid. 

b. Trainers want to integrate students’ capabilities in team exercises and stretch 
everyone. They want to elicit thinking through student identification of options and 
variables. Trainers suggest that the tool include an option that allows them to 
increase exercise difficulty based on student performance (“teach to each” versus 
“teach to mean”). An example is the ability to go from a two-channel “on/off’ 
scenario to a five-channel one, increasing the number of options in the variables 
offered. They also suggest adding an assessment method to tell what would have 
happened if the student had chosen differently, following the branches, and a 
method to anticipate sequels. 

Issue: Currently there is no scalability in the training module. Specific requirements for 
extension modules are yet to be determined. 

3. Feedback: 

a. Subjective weightings/rankings are only as good as the student’s expertise and 
information base. The exercise of decomposing the factors that affect the TA and 
watching how changing weights for individual factors changes the probability of 
success is valuable in itself. Trainers suggested that they would like to see feedback. 
They envisioned the following training scenario: 

• For a given exercise, the system provides a series of variables that form 
three distinct paths to follow (Path A=50% of the solution, Path B=100%, 
and Path C=25%). 

• System collects data on the students’ selection of variables and how they 
justified them. 

• System identifies the incorrect paths and the shows cascading effects from 
following the wrong route. 

• System shows the correct path and its cascade of effects. 

• Trainer tracks student progress; if at any point, the student chooses A, the 
trainer can show why that path is not optimal, but if the student chooses C, 
the trainer knows to take him/her back to basics. 
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Issue : Hardwiring, as described above, cuts down on options, but the trainers say that is 
all right for a training aid. Providing only this option would not necessarily provide a 
close match with reality, where there is often no right answer. 

b. However, the system could also be designed to allow freedom of 

thought/movement, offering a best choice answer and several others that varied in 
degree of usefulness, and allowing the student to work out a best possible solution. 
In this mode, the system again would show possible outcomes. 

Issue : Including both of these modes would allow the student to progress from canned 
classroom scenarios to real world scenarios. It would also provide a method for 
providing increased difficulty for more able students. 

Student Tool Use 

1. Student Task: 

a. The classes mirror every step of the planning process, taking the student from 
“hands-on” trainer-supported exercises to a “hands-off’ capstone training effort. 
Trainers provide the students with a set of Joint Task Force (JTF) objectives and 
plug in standardized objectives for the exercise, depending on the scenario (e.g., 
eight objectives for phase one). Influence operations objectives will be the sub¬ 
objectives (influence nation command, influence political structure, etc.) Each 
individual discipline can answer the need. Students learn to write their own 
objectives and how to modify Air Staff concepts to perception management needs 
and integrate counter-intelligence perspectives. Students must learn to support why 
a non-kinetic option is preferable to convince the AOC. They must be able to 
present their plan, provide appropriate details, make a strong argument, show the 
effects and the effects desirability, and defend the plan’s solution. 

Issue: IOTA must be updated to include the entire planning process; the designers 
intend for the tool to mirror the language used in AOC planning. As the AOC planning 
process is under development, language changes may have to be updated/updatable, 
(measures of merit, should be included in the program, but need to be adjustable as 
analysis renders them inappropriate.) 

b. In the new exercises, all targets go “on deck” no matter how they are to be 
prosecuted, only the restricted target list will be retained. Kinetic and non-kinetic 
options will be de-conflicted (e.g., will ensure that there is no close air support 
activity scheduled for the vicinity of leaflet drops). The point is to integrate the air 
picture for the day and deconflict all missions at once. 

Issue: How the deconfliction aspect will be managed is not yet articulated. 

c. Students will practice assuming different roles in the AOC. Hands-on exercises will 
require both individual effort, with each student using different expertise to do 
his/her own portion, and group coordination, integrating and deconflicting 
individual efforts. Lesson includes teaching students how to present to staff 
estimates of non-kinetic actions. In order to accomplish the task, students also must 
learn how to manage group dynamics. 

Issue: How the students will collaborate is not yet articulated. 

2. Task Support: 
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a. Classification: At IOIC, students will stay on JWICS, with SIPRNET and Non- 
Secure Internet Protocol Router Network (NIPRNET) for research and reach-back 
capabilities. MD will be done at the SECRET/NOFORN level, and will incorporate 
national level entities on JWICS. Exercises may require going to a high level 
classification. 

Issue : Unclassified paradigms for scenarios will need to be built; there will be nothing 
classified in the developmental design. For the MD section, the design will need to 
separate high and low classification aspects (multi-level security?). 

b. MD, OPSEC and PSYOP employ somewhat different terminologies to reflect their 
different perspectives. OPSEC is the only track that asks the student to look at how 
their plan will both impact US activities (giving Indications and Warnings; I&W) 
and US perceptions. 

Issue : Language usage will have to be carefully documented and managed. 

Additionally, the OPSEC track may pose difficulties for students as they have to focus 
their objectives differently than in PSYOP and MD. The OPSEC objective is to remove 
I&W, whereas the MD objective is to exploit them. 

c. How well the students know where to get data will vary by student; students are 
given lists of urls in class that the instructors have compiled. 

Issue: The instructor-supplied urls can be integrated into the internet browser as 
favorites and the file emailed for importation in the students’ home systems. 

d. Students must factor in cultural analysis issues (e.g., how to communicate with non¬ 
literate populations). Students are taught to leverage preconceived adversarial and 
military mindsets. 

Issue: PYSOP recommendations are turned over to the Army for implementation. The 
actual method of implementation is not determined by the student. 

e. In the current version of the tool, the focus is on the factors that influence Target 
Audience behavior, the estimated difficulty friendly forces will experience directing 
TA behavior toward the goal state. 

Issue: The goal state is represented by standard PSYOP objectives; the actual PSYOP 
plan is not captured when users project probability of success influencing TA behavior. 

f. PSYOP doctrine is in a state of flux. The new JP 2.5.3 draft hasn’t been signed yet; 
neither has the new OPSEC draft. 

Issue: The changes in doctrine will probably impact lesson plans and decision support 
tool requirements. Additionally, according to the trainers, current AF training focuses 
on deliberate and contingency planning for force execution missions. Training doesn’t 
cover how to plan for Humanitarian Assistance (HA), Noncombatant Evacuation 
Operations (NEO), and Civil Affairs (CA) outside of hotspots in the Middle East. 
Training doesn’t cover planning for nation building or planning for handing over an 
area to the ambassador for reconstruction. Training doesn’t cover how to redeploy, 
reconstitute or employ forces in interim periods and how to get people in and out 
safely. PSYOP is concerned with developing ways to endear US forces to the 
population to reduce risk and increase cooperation. Any future effort to add in these 
training modules will extend required scenarios considerably. 
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4.1.2 Elicitation Findings/Discussion Points for Usability (Focus on the User) 

User Characteristics 

1. Class Demographics: 

a. Joint class members are integrated by service and rank (range from E-2, E3 to Lt 
Col). Members exhibit differential levels of expertise; levels of expertise range 
from 2 to 3 years (beginner) to 15 years (expert). 

Issue : Class tools need to be scalable to teach and test multiple levels of expertise. 

b. There are one to two instructors per ~20-person Influence Operations (10) class. 
The class focuses on Falconer AOCs. Class population comes from the nine 
Information Warfare Flights (IWFs). Class constitution is governed by the gaining 
unit and their needs. Percentages change from class to class. 

Issue : Student need for instructor attention will vary. Class tools need to be self- 
supporting to some degree to allow students to work independently. 

c. Students are taught how to support all 10 disciplines used in AOC but when they 
report to their IWFs, they will fill whatever slots are open, performing intelligence 
preparation of the battlespace (IPB) for deliberate planning and continuous update 
functions. During contingencies, approximately Vi the flight will go with the AOC; 
the rest will remain with the IWF, supplying reachback. 

Issue : There is a concern that students may forget lessons that aren’t reinforced over 
time. 

2. Student Computer Expertise: 

a. The tool is Hyper Text Markup Fanguage (HTMF)-based and will be accessed as a 
web page. The web page interface is desirable as all students should have 
familiarity with a web environment; students are expected to know how to use 
typical internet browser functions. 

Issue : The tool needs to incorporate all the capabilities of a web environment 
(, highlight, copy, paste, save as). Aids should include pop ups, hover, find, and drill 
down capabilities. Users should be able to jump to mail to output to other 
organizations. 

b. Student briefings, which simulate presentations to AOC decision makers, are done 
in PowerPoint (however, trainers express a desire for the system to integrate with 
all MS Office). 

Issue: The tool currently supports copy and paste functions, but automating transfer of 
information from the tool to the PowerPoint presentation would save time and effort. 
Trainers want the program to integrate with Microsoft Office and be able to “push” to 
Theater Battle Management Core Systems (TBMCS). 

Task Characteristics 

1. Task Overview: 

a. Tasks are constrained by class time. In the first part of the course, trainers give an 
overview of the different disciplines, the standard measures of behavior, and how to 
measure behavior. In the second phase, subject matter experts (SMEs) give units of 
instruction on their specific disciplines, use slides accompanied by slide notes. The 
course moves from rote memory exercises to demonstrations of subject matter 
expertise. 

Issue : Currently, students get three weeks of practice in the planning stage. Eventually, 
trainers will integrate practice exercises into more of the course. Instructors and 
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students will create new scenarios to add to IOTA’s existing scenario database. As 
more information is acquired, there will be a need to update the influence operations 
factors to reflect increased understanding. 

b. Using the tool prototype, for a given scenario, students should be able to identify 
operational and tactical objectives and associated measures of effectiveness (MOEs), 
characterize the target audience and identify opportunities, limiting factors 
(LIMFACs) and susceptibilities, and rank and weight the susceptibilities. The 
students should be able to give a level of confidence in information and a level of 
effectiveness (ability to reach the susceptibility); the student should be able to weight 
the likelihood of success. 

Issue : Students will have access to SIPRNET, NIPRNET, and JWICS. The user must 
be able to integrate database access and exercise activities. The students use IWPC, 
InfoWorkspace (IWS), and Information Operations Navigator (ION); some degree of 
IOTA integration may be required. 

c. To complete the task, students should be able to use available databases to research 
culture and leadership aspects to determine how to affect the population and the 
leadership. 

Issue : Navigation between planning and decision support tools and supporting 
databases should require minimal effort and minimal time. No picture of what the 
screen will look like while the student moves between application and reachback 
capabilities is currently articulated. How the system looks, how the students will keep 
track of where they are between applications, how quickly and easily they can navigate 
and how quickly and easily the database supports their information quests are all 
human factors integration issues. 

GUI Environment 

1. Common Look and Feel: 

a. The IOTA tool, like some other applications students will use, is web-based. Other 
applications are MS Office-based or employ the standard Windows work 
environment. 

Issue : The IOTA tool graphical user interface (GUI) should leverage student familiarity 
with the MS Internet Explorer web browser and Office suite GUIs. It should also 
leverage all Windows “Help” capabilities and user aids (Help topics, Table of 
Contents, Index, Glossary, context-sensitive Help, etc.) 

Operational Environment 

1. Environmental Characteristics: 

a. Students will be working as teams to create their recommendations. Students will 
represent the different disciplines/roles found in the AOC. 

Issue : Students need to be able to work alone or collaboratively. Students need to be 
able to deconflict their respective plans. 
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4.1.3 Requirements 

1. Usefulness Criteria (How effective and flexible is IOTA in supporting the work of the 
IO instructor and student?): 

a. Effectiveness 

i. Ensure IOTA supports IO planning for all phases of an OPLAN 

ii. Ensure Objectives are entered in correct terminology and structure and can 
have associated success indicators and measures of merit inserted 

iii. Account for uniqueness of each track (e.g. MD process and target distinctions 
from PSYOP process/targets, OPSEC process/targets) 

iv. Take advantage of synergies among tracks 

v. Account for risk as well as probability of success in presentation of output 

vi. Ensure each module (PA, MD, PSYOP, OPSEC) reflects the process for that 
track (not all processes are the same) 

vii. Ensure IOTA ontology/taxonomy mirrors the language of the course materials 
and the relevant discipline 

viii. Ensure IOTA reinforces the instructors presentation of the course work 

• IOTA presentation mirrors IO planning process taught in lessons 

• IOTA provides cues/prompts when reachback is required 

• Import methodology and format for reachback simulates process 
taught in lessons 

ix. Ensure IOTA reinforces student understanding of the course work 

• IOTA presentation is familiar to student and mirrors process taught in 
lessons 

• Understanding of when reachback is needed is clear and 
straightforward 

• Easy cues/prompts to access needed data sources (reachback) 

• Student can import reachback data as required 

• Interoperability with other applications - student can provide model 
output in required presentation formats 

x. Ensure IOTA provides adequate scalability 

• IOTA can be used for beginning and challenged students and advanced 
students can take advantage of features to push the analysis envelope 
and bring in more expertise and sophistication 

• Ability to control versions, configuration of tool and data 

xi. Ensure IOTA supports student/student and student/instructor collaboration 

• Input and results be exchanged, shared 

• Framework to support collaboration 

• Internal (within schoolhouse) and external (reachback) collaboration 

• Ensure ability to integrate IO track (MD, PA, PSYOP, OPSEC) plans 
(build supporting objectives and target assessments) 

• Ensure ability to de-conflict IO track plans (flag objectives and 
analyses that will negatively impact plans for other IO tracks) 

• Output directly supports presentation of an integrated, de-conflicted IO 
plan for a given scenario, mission objective 


17 

Approved for public release; distribution unlimited. 



xii. Ensure IOTA provides adequate extensibility 

• Students can use this tool when they report to their assigned units 

• IOTA can be implemented in IWPC or Sensor Harvest as a tool to 
support deliberate and crisis action 10 operational planning 

• Compatibility/extensibility to ION (joint community) 

xiii. Ensure IOTA provides tracking, both of student rationales and grades 

• A way to capture student thought process for each input to the model 
(error traceability, rationale, justification, support for end 
recommendations and outbrief) - notes pages 

• Three-level (red, yellow, green) student grading at completion of 
model runs with appropriate feedback and indications of where errors 
were made, improvements could be made 

• Guided discovery 

b. Flexibility 

i. Easy to update and expand to advanced versions, new modules, refined 
modules 

ii. Ability to access pre-canned objectives, modify pre-set objectives, add new 
objectives 

2. Usability Criteria (How easy is this tool to use?) 

a. Communication/Integration 

i. Ensure IOTA supports implementation on JWICS 

ii. Ensure IOTA can access SIPRNET and NIPRNET source data 

b. Situation awareness/Sensemaking 

i. Ensure IOTA provides event and change detection 

ii. Ensure IOTA provides visualization support 

• Graphical display of “what if’ and impact analysis 

• Progress bar to indicate what steps have been successfully 
accomplished 

• Buttons to move among track modules (PA, PSYOP, MD, OPSEC) 

• Glossary 

iii. Ensure IOTA maps output to what’s needed for target planning presentation 
(e.g. targeting sheet) 

c. Error detection and recovery (student) 

i. Ensure IOTA provides Help functions - useful, comprehensive, clear and easy 
to use 

ii. Ensure IOTA provides indicators of invalid input (e.g. weights) - “need to re¬ 
evaluate” 

iii. Ensure IOTA provides indicators of output that does not make sense 

d. Predictive capabilities 

i. Provide “What-if ’ analysis 

ii. Provide Sensitivity analysis 

iii. Provide Impact analysis 

e. Interoperability 

i. Ensure IOTA search engine integration (reachback) 

ii. Ensure IOTA provides pointers, aids to access existing data sources 
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• Databases (various organizations) 

• Web sites (instructor bookmarks) 

• Documents 

• Media 

• SMEs 

iii. Ensure IOTA has a “Send to” function for checking, collaboration 

4.2 Knowledge Elicitation Trip 2 

The second knowledge elicitation trip provided new opportunities to flesh out customer 
requirements through examination of a proposed system design. The design was originally 
intended to undergo user testing in a live classroom demonstration. However, the agreed upon 
date for the demonstration occurred during a session break; in consequence, user testing was 
done by instructors. A formal evaluation of the proposed system design, specifically directed 
under the statement of work, was also conducted and submitted to the government. The customer 
demonstration, coupled with the evaluation, illustrated the limitations of the employment of a 
browser-based forms approach taken from the PYSOP PT. The user testing opportunity drew 
forth more fully defined customer requirements, prompting the proposal of an RCP solution; 
requirements definition was immediately initiated to support the design shift. It was during this 
requirements collection that, in order to emphasize the Influence Operations nature of the tool 
that its title became IFOTA. A partial representation of system requirements is presented in 
Table 1. More complete requirements documentation is found in Appendix A. 


Table 1. A Partial Representation of IFOTA Requirements. 


1 . 

2 . 

3. 

4. 

5. 

6 . 

7. 

8 . 
9. 

10 . 

11 . 

12 . 

13. 

14. 

15. 

16. 

17 . 

18. 

19. 

20 . 
21 . 


General 

The IFOTA shal 
The IFOTA shal 
The IFOTA shal 
The IFOTA shal 


(Dll COE) and Xerox usability standards 


The IFOTA shal 
The IFOTA shal 
The IFOTA shal 
The IFOTA shal 
The IFOTA shal 
The IFOTA shal 
The IFOTA shal 
The IFOTA shal 
The IFOTA shal 
The IFOTA shal 
The IFOTA shal 
The IFOTA shal 


(SMART) input screens 


The IFOTA shal 
The IFOTA shal 
The IFOTA shal 
The IFOTA shal 
The IFOTA shal 


be able to be installed and run on a JWICS system 
have a Windows look and feel 

have a main menu with submenus and toolbar with icon buttons 

conform to Defense Information Infrastructure Common Operating Environment 


open to a blank window 

provide a file chooser to display existing files for selection 

provide scenario search capability 

provide a login function 

allow the user to open existing files 

allow the user to create new files 

allow the user to save files 

allow the user to modify files according to permissions 
ensure students can't overwrite scenarios from library 
allow students to modify (add/delete/change) their own work 
allow the user to print whole files 

allow the user to suppress printing Subject Matter Analysis & Research Toolkit 


allow the user to suppress printing SMART results 
allow the user to print the scenario summary 
allow the user to print single/multiple page(s) 

allow cut, copy, and paste between fields, screens, windows and programs 
allow unlimited undo/redo and repeat for all text entries _ 
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22. The IFOTA shall provide a Help function 

23. The IFOTA shall provide contextual help 

24. The IFOTA shall provide a glossary encompassing the terms from the Joint Air Estimate Process 
(JAEP), 10 joint publications (JPs), 10 Air Force Doctrine Documents (AFDDs), and 10 Air Force 
Tactics, Techniques & Procedures (AFTTPs) 

25. The IFOTA shall display software version and Program Manager/Developer contact information 
under Help:About IFOTA 

26. The IFOTA shall display descriptive titles on all windows and dialog boxes 

27. The IFOTA shall permit the user to open, manage, and work in multiple windows (up to six?) 

28. The IFOTA shall permit the user to open multiple scenario files 

29. The IFOTA shall allow the user to open multiple modules in multiple windows 

30. The IFOTA shall allow the user to open multiple instances of the same module 

31. The IFOTA shall allow the user to open old scenarios concurrent with new scenario 

32. The IFOTA shall allow the user to navigate through screens in a maximum of 5 steps 

33. The IFOTA shall have PSYOP, MD, OPSEC, and PA modules 

34. The IFOTA shall be extensible to include a future Cl module 

35. The IFOTA shall have a module that accepts/displays electronic warfare (EW) and net warfare 
(NW) planning entries 

36. The IFOTA shall have an Instructor module 

37. The IFOTA shall use terminology that meets 39th IOS approval 

38. The IFOTA shall use procedures that meet 39th IOS approval 

39. The IFOTA shall identify and keep track of where each planner is within the 5 operational phases 

40. The IFOTA shall identify and keep track of where each planner is within the 72-hour planning 

cycle 

41. The IFOTA shall display plans across operational phases and planning cycles 

42. The IFOTA shall accept and maintain integrity of task branches 

43. The IFOTA shall have a status screen that summarizes current status for each module 

44. The IFOTA shall have a deconfliction/coordination function 

45. The IFOTA shall recognize workgroup members 

46. The IFOTA shall allow workgroup members to view each others' work 

47. The IFOTA shall allow chat-style communication between workgroup members 

48. The IFOTA shall capture chat communication between workgroup members 

49. The IFOTA shall provide a Request for Information (RFI) management function 

50. The IFOTA shall allow students to enter their own decision selections 

51. The IFOTA shall provide graceful shutdown 

52. The IFOTA shall be designed to be extensible 

53. The IFOTA shall be designed to facilitate integration with IOPC-J 
Login Function 

54. The IFOTA shall prompt the student to login (appropriate permissions will be keyed to login) 

55. The IFOTA shall identify types of users and work group members through coded logins 

56. The IFOTA shall prompt the student to select a module in the login screen 

57. The IFOTA shall use login information to direct file save paths 

Search Function 

58. The IFOTA shall provide scenario search capability on a single screen through a clickable world 
map and a text-based search function 

59. The IFOTA shall provide a geographically-based scenario search capability through a Major 
Command (MAJCOM) map that permits the user to drill down to specific countries and local areas 
to obtain the scenario files for the chosen area. 

60- The IFOTA shall provide a text search capability that permits the user to obtain the scenario files 
for specific ethnocultural groups, tactical tasks, discipline-specific tasks, or geographic locales 
61 ■ The IFOTA shall prompt the scenario creator/modifier to tag the scenario by geographic locale, 
ethnocultural group, and tactical/support tasks _ 
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62. The IFOTA shall permit the scenario file to be opened from the scenario search results display 

Menu/Tool Bar 

63. The IFOTA shall provide access to all functions through a menu bar with main menus and 
submenus 

64. The IFOTA shall display keystroke combination shortcuts for actions on the submenus 

65. The IFOTA shall identify icon function with hovertext 

66. The IFOTA shall provide alternate access to frequently used functions through a tool bar 

67. The IFOTA shall include icons to customize the tool bar to include any function 

Help Functions 

68. The IFOTA shall provide a "WinHelp" or "HTML Help" Help function 

69. The IFOTA shall allow Help to remain onscreen while the user is working in the file 

70. The IFOTA Help screens shall be dockable/undockable 

71. The IFOTA Help screens shall be resizable 

72. The IFOTA shall allow the user to print Help entries 

73. The IFOTA Help system shall include definitions of terms, directions for procedures, and links to 
support material provided by 39th IOS 

74. The IFOTA shall provide contextual help at all decision points 

75. The IFOTA shall provide contextual help in the form of "on-demand" popups 

76. The IFOTA shall access dialog box contextual help using a question mark icon 

77. The IFOTA shall provide contextual help in the form of text definitions for course vocabulary items 

78. The IFOTA shall highlight text entries that have associated contextual help 

79. The IFOTA shall access highlighted contextual help items by doubleclicking on highlighted text 
Instructor Module 

80. The IFOTA shall allow instructors to view students' work in real time 

81. The IFOTA shall associate workgroup and student identifications with each saved file 

82. The IFOTA shall capture justifications and references for student's work 

83. The IFOTA shall allow instructors to modify (add/delete/change) student decision point selections 
and save modifications to a new file 

84. The IFOTA shall notify the student the instructor has modified the student's work 

85. The IFOTA shall allow the student to transfer to the modified file 

86. The IFOTA shall capture grades for student work 

87. The IFOTA shall capture student actions in a readable log file 

88. The IFOTA shall permit instructors to create scenario templates 

89. The IFOTA shall permit instructors to modify scenario templates 

90. The IFOTA shall allow instructors to modify scenario data 

91 ■ The IFOTA shall allow instructors/staff to create new scenarios 

92. The IFOTA shall provide a method for testing students 

93. The IFOTA shall provide a method for grading and annotating tests 

94. The IFOTA shall provide a method for calculating grades 

95. The IFOTA shall capture summary/final grades 
Initiation 

96. The IFOTA shall open each new work session with the JWICS regional commands map 

97. The IFOTA shall display regional command member countries in matrix form 

98. The IFOTA shall link to basic political and sociocultural information for each country 
99- The IFOTA shall allow the user to select a single country 

100. The IFOTA shall display a map for each country 

101. The IFOTA shall link to demographic, political and sociocultural information for each distinct region 
within the country 

102. The IFOTA shall open each scenario with the summary sheet 

103. The IFOTA shall provide a list of combined operational tasks organized by service and operational 

_ phase _ 
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104. The IFOTA shall provide success indicators for each operational task 

105. The IFOTA shall allow the user to select operational task(s) and success indicators 

106. The IFOTA shall provide an example list of Air Force tactical objectives organized by service it 
supports 

107. The IFOTA shall provide example measures of effectiveness (MOEs) for each tactical objective 

108. The IFOTA shall allow the user to select/write up to 5 tactical objectives 

109. The IFOTA shall allow the user to select/write MOEs for each objective 

110. The IFOTA shall provide an example list of Air Force tactical tasks organized by service it 
supports 

111- The IFOTA shall provide example measures of performance (MOPs) for each tactical task 

112. The IFOTA shall allow the user to select/write up to 5 tactical tasks 

113. The IFOTA shall allow the user to select/write MOPs for each task 

114. The IFOTA shall allow the user to enter own tactical tasks 

115. The IFOTA shall allow the user to enter own MOPs 

116. The IFOTA shall show task branches 

117. The IFOTA shall allow the user to create task branches 

118. The IFOTA scenario shall identify the current planning stage 

119- The IFOTA scenario shall identify the current operational phase 
Status/Summary Screen Function 

120. The IFOTA shall have a status screen that summarizes current status for each module 

121. The IFOTA shall display current information from each module on the summary screen(s) 

122. The IFOTA shall display information from each module from the following fields on the summary 

screen(s): operational objective, SI, tactical objective, MOE, tactical task, MOP, tactical support 
task, MOP, target audience, target action, rationale, link to synchronization matrix 

123. The IFOTA shall pull summary information from the corresponding data entry fields in each 
individual module 

124. The IFOTA shall the status screen will update automatically whenever any data that feed the 
status fields change 

125. The IFOTA shall have a deconfliction version of the summary screen with checkboxes to indicate 
deconfliction has been accomplished 

Deconfliction/Coordination Function 

126. The IFOTA shall have a deconfliction/coordination feature that prompts the user to 
deconflict/coordinate with other disciplines 

127. The IFOTA shall display the deconfliction screen whenever the student reaches an identified 
deconfliction point in the process 

128. The IFOTA shall have a deconfliction button that brings up the summary/deconfliction screen at 
user command 

129. The IFOTA shall use the status screen for the deconfliction/coordination function 

130. The IFOTA shall display checkboxes by each deconfliction action in the deconfliction function 

131. The IFOTA shall timestamp each deconfliction/coordination action 

132. The IFOTA shall open a popup text field to capture the student's deconfliction action whenever the 
student fills in a deconfliction checkbox 

133. The IFOTA shall open a popup text field to capture the student's deconfliction rationale whenever 
the student fills in a deconfliction checkbox 

134. The IFOTA shall not allow the student to proceed until the student has checked each box and 
entered text in each action description text field 

Multiple Window Capability 

135. The IFOTA shall permit the user to manage multiple windows 

136. The IFOTA shall allow the user to tile windows horizontally and vertically 

137. The IFOTA shall allow the user to resize all windows 

138. The IFOTA shall allow the user to move all windows 

139. The IFOTA shall allow the user to close all windows 
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140. The IFOTA shal 

141. The IFOTA shal 

142. The IFOTA shal 

143. The IFOTA shal 

RFI Managemen 

144. The IFOTA shal 

145. The IFOTA shal 

146. The IFOTA shal 

tasks 

147. The IFOTA shal 

148. The IFOTA shal 

149. The IFOTA shal 

PSYOP Module 

150. The IFOTA shal 

151. The IFOTA shal 

152. The IFOTA shal 

153. The IFOTA shal 

154. The IFOTA shal 

155. The IFOTA shal 

156. The IFOTA shal 

157. The IFOTA shal 

158. The IFOTA shal 

159. The IFOTA shal 

160. The IFOTA shal 

161. The IFOTA shal 

demographic inf 

162. The IFOTA shal 

163. The IFOTA shal 

164. The IFOTA shal 

165. The IFOTA shal 

166. The IFOTA shal 

167. The IFOTA shal 

168. The IFOTA shal 

169. The IFOTA shal 

170. The IFOTA shal 

171. The IFOTA shal 

172. The IFOTA shal 

173. The IFOTA shal 

174. The IFOTA shal 

175. The IFOTA shal 

176. The IFOTA shal 

knowledge) 

177. The IFOTA shal 

178. The IFOTA shal 

179. The IFOTA shal 

180. The IFOTA shal 

181. The IFOTA shal 

182. The IFOTA shal 

183. The IFOTA shal 

184. The IFOTA shal 

185. The IFOTA shal 


allow the user to minimize all windows 

allow the user to move freely between windows 

include a toggle capability to enlarge window in which student is working 

allow the user to tab between windows 

it Function 

provide a Coliseum RFI template 

provide the means to make other RFI templates 

allow the user to draft RFIs to obtain information necessary to complete scenario 

capture RFIs for instructor 

simulate tracking RFI status 

allow the user to create assessment collection RFIs 

provide example PSYOP-specific tactical support tasks 
allow the user to select up to ? tactical support task(s) for each tactical task 
allow the user to enter own tactical support tasks 
provide space to insert MOPs for each tactical support task 
give an example measure of performance 
capture RFIs needed to perform assessment (in Coliseum format) 
pop up deconfliction screen after tactical support task(s) are selected 
capture/display themes and symbols for each branch 
allow the user to enter own message and theme for each branch 
pop up a deconfliction screen after messages and themes are selected 
capture justification for theme/symbol selection 
list (or link to) target audiences and specific political/sociocultural and 
ormation 

allow the user to select a target audience 

allow the user to enter a target audience 

capture justification for target audience selection 

generate RFIs needed to fill knowledge gap (in Coliseum format) 

pop up deconfliction screen after target audience is selected 

provide a dropdown list of example target actions 

allow the user to enter own target action 

allow the user to select/enter target action 

provide example MOPs/MOEs 

allow the user to enter MOPs/MOEs 

capture collection requests for target action assessment 

capture justification for how target action supports messages/themes/symbols 

pop up deconfliction screen after target action is selected 

list target audience/target action specific situational/cultural factors 

provide default selection of applicable situational/cultural factors (from embedded 


allow the user to modify applicable situational/cultural factors 

allow the user to enter own situational/cultural factors 

list possible situational/cultural conditions (from embedded knowledge) 

allow the user to select applicable conditions 

allow the user to enter new conditions 

capture user's prioritization (ranking) of conditions (vulnerabilities) 

capture user's relative weighting of conditions (susceptibilities) 

capture user's Red/Yellow/Green (stoplight metaphor) assessment 

allow the user to skip SMART model and go directly to delivery method selection 
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186. The IFOTA shall collect SMART model decision criteria 

187. The IFOTA shall use scales to capture user assessments required for SMART model 

188. The IFOTA shall generate RFIs needed to fill SMART criteria knowledge gap (in Coliseum format) 

189. The IFOTA shall display SMART model evaluations 

190. The IFOTA shall allow the user to modify SMART model inputs and rerun algorithm 

191 ■ The IFOTA shall provide an example list of delivery methods 

192. The IFOTA shall allow the user to select/write a delivery method 

193. The IFOTA shall pop up deconfliction screen after delivery method is selected 

194. The IFOTA shall provide a PSYOP summary relating PSYOP tasks and MOPs to tactical 

tasks/MOPs and tactical objectives/MOEs 

195. The IFOTA shall capture collection requests for course of action assessment 

196. The IFOTA shall permit the student to deconflict across planning cycle and operational phases 


Not all of the requirements collected for the system were approved for or intended to be met in 
the initial system. The SMART model and associated algorithms were dropped. Many of the 
proposed Help, Deconfliction, and Instructor functions were deferred to later iterations or 
dropped. 

4.2.1 Processes 

The following flow diagrams illustrate the understanding of desired system function obtained 
during elicitation. The original elicitation did not cover Cl, although it was requested for a later 
iteration and elicitations were conducted at that time to create a Cl process flow. It is included 
here for completeness. 

Figure 7 describes the login process and opening a scenario. Student planning efforts were tied to 
planning scenarios that included situation descriptions and simulated command guidance. 
Supplementary materials, such as country reports, the CIA World Fact Book, and bookmarked 
web pages of interest were available to simulate planning support documents. Scenarios were 
catalogued by type of scenario, region of interest, and sociocultural similarity (at this time, 
represented by religious affiliation). Students could look for completed scenarios to study them 
and borrow concepts or open an assigned scenario to begin planning efforts. Students were to 
begin by examining command guidance identifying operational and success indicators as well as 
command directed themes and messages. Figure 8 shows discipline-specific activity sequences. 
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4.2.2 Task Descriptions 


Open IFOTA )• Doubleclick program icon 

Assumptions: J -Login Screen opens 

•Student role assigned; 
student login brings up 
student module 
•Instructor login brings up 
instructor module . 

| -Selection screen opens 




’Identifies User Type, Work Group & Role 
’Assigns permissions; links to WG members 
’Opens student or instructor module 



Initiating activities 



Terminating activities 


Figure 7. Initiating and terminating an IFOTA planning effort. 
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5.0 IFOTA DEVELOPMENT 

IFOTA 1.0 guided the student through the PSYOP, OPSEC, PA, and MD student 
planning capabilities, capturing student rationales and deconfliction efforts. IFOTA 1.0 
promoted collaborative work among 10 disciplines and allowed instructors to monitor 
and communicate with students. 

The tasking set forth in the Statement of Work directed the transition of the IFOTA 
browser-based prototype from an existing, customer-mandated, planning capability into a 
training aid to expedite, enhance, and enrich the training of inexperienced Influence 
Operations trainees in the successful planning and integration of Influence Operations 
campaigns. Two major tasks were envisioned. The first area focused on developing 
scenarios, modules, and exercises resulting in a software package, training on the 
software, and a software user’s manual for IFOTA. The second major task area focused 
on an integrated effort to ensure that the IFOTA product, training, and documentation 
would be both usable and useful. It directed the empirically based evaluation and 
assessment of usability and usefulness through scenario-based testing by subject matter 
experts. Specific development goals included the following: 

• Transition the existing PSYOP PT into an IFOTA encompassing training in 
planning for PSYOP, MD, OPSEC and PA and incorporating software 
modifications (e.g. sliding bars and color displays) from review and critique of the 
existing PSYOP PT. 

• Design, develop, and implement a new module to encompass the planning 
component of MD, including OPSEC and allowing deconfliction of MD, PSYOP 
and PA mission objectives. Identify a taxonomy of potential objectives/missions, 
design an interface, and integrate delivery methods and target audience 
vulnerabilities. 

• Design, develop, and implement a new module to encompass the planning 
component of PA and allowing deconfliction of PA mission, PSYOP, MD, and 
OPSEC mission objectives. Identify a taxonomy of potential objectives/missions, 
design an interface, and integrate delivery methods and target audience 
vulnerabilities. 

• Design, develop, and implement a new module to encompass the functional aspect 
of identifying and selecting optimum delivery methods. Identify a taxonomy of 
delivery methods, design the software interface, and integrate the delivery method 
(or methods) that best exploit the vulnerabilities of the target audience. 

Additional tasks included development of two IFO scenarios involving one culture, 
identifying objectives, target audience, and providing a list of cultural/situational 
factors/vulnerabilities. The conduct of a live classroom exercise demonstration, and a 
usability/usefulness focused design evaluation and recommendations. The live classroom 
exercise was reconfigured as an interactive demonstration using instructors and selected 
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SMEs, due to classroom scheduling difficulties. The two scenarios were delivered to the 
government separately, as was the requested software evaluation. Figure 9 shows a 
screenshot from IFOTA 1.0. 


File Edit View Tools Modules Windows Help 

] ■ ti h + • ■ x | ■* n | ® a v* 1 00 .ft | ^ a | a » a a a 



Figure 9. IFOTA 1.0 multi-tabbed PSYOP scenario showing evaluation of TA resistance 

IFOTA 2.0 reorganized the screen real estate to provide multiple dockable/undockable 
panes surrounding a main work area, added a Cl module and a more fully functional Help 
system. Figure 10 shows a screenshot from IFOTA 2.0. 



Figure 10. IFOTA 2.0 screenshot illustr; 
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IFOTA 3.0 added the following functionalities: 

• Enhanced Architecture 

o Oracle database 

o J2EE for component-based multi-tier enterprise 

o Eclipse runtime environment provides common interface for extensions to 
core 10 planning capabilities (enhanced plug-ins) 

• Spell Check capability 

• Gantt Chart (Time-Series Views) for temporal view of plans 

o Visual cue for deconfliction 

• Combo Boxes 

o Decision aid support 
o Include Operational Taxonomy 

Figure 11 shows the synchronization matrix (Time-Series View) from IFOTA 3.0. 



Figure 11. IFOTA 3.0 User interface showing addition of Time Series View tab and function 


IFOTA 4.0 added the following functionalities: 

• Deconfliction Tool 

o Decision-Aid for deconfliction of IFO plans 

• COA Rating 

o PSYOP-specific, cost/benefit-based, post-wargaming COA selection 
decision matrix 

• PSYOP Estimate Template 

o PSYOP Estimate of the Situation template that guides and documents 
PSYOP estimate development activities 

• Database/Back-end Upgrade 

• Additional Scenarios and Data in Database 
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• Worksheets and User Guide updates 


Figure 12 shows the deconfliction function in IFOTA 4.0. 



Figure 12. IFOTA 4.0 showing deconfliction of MD COA and COA weighting 


The final IFOTA task also included development of several IFOTA-compatible scenarios 
for use in integrated 10 training. The scenarios, which included anti-government and anti- 
US protest scenarios in several countries, a multinational peacekeeping scenario, a 
Petroleum, Oil and Lubricant (POL) contamination scenario, an ethnic tensions scenario 
and an espionage recruiting scenario, were delivered to the government separately. 

5.1 IFOTA Technical Architecture 

IFOTA technical maturity and enterprise scalability has progressed through releases. 

IFOTA 1.0 software used a two tiered client server architecture, with a Java Swing client 
and an Oracle Database. Java Data Base Connectivity (JDBC) was used to handle 
database transactions between client and database. The architecture’s technical simplicity 
enabled rapid development responsiveness to user requirements. With more mature 
requirements, subsequent versions (2.0 through 4.0) utilized a three tiered architecture. 

Figure 13 distinguishes the high-level components of the IFOTA architecture within its three¬ 
tiered architecture: a database tier, a business logic tier and a workstation/presentation tier. 
IFOTA uses an Oracle database system to handle the data persistence needs. A Java 2 
Enterprise Edition (J2EE) middleware solution based on JBoss Application Server version 4 
is used for the business logic processing needs. The workstation/presentation tier 
representing the user interface is built upon the Eclipse RCP. 
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The communication between the tiers is accomplished through a number of standards. 
Remote Method Invocation (RMI) is used as the main information transfer mechanism 
between the client and the JBoss server middleware. Java Messaging Service (JMS) is 
leveraged for the propagation of influence operation plan updates between the business 
logic services and the active listening clients. The persistence of data from the business 
logic tier to the database tier uses J2EE connection pooling and JDBC. 

Data access/transfer object patterns were used to abstract data persistent implementations 
and transfer implementations from the business logic. Enterprise Java Beans (EJB) 
version 2.0 was used to define entity relationships and persistent properties to the data 
tier communication methods. 

A fagadc design pattern is used to limit coupling between the client system and the 
business logic/application services. Stateless session beans are used to limit scalability 
barriers in the middle tier. Other J2EE best practices are leveraged throughout the middle 
tier, such as restricting direct communication with the file system. Figure 14 shows a 
system component view. 



Figure 14. IFOTA system component view 
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IFOTA development employed UML for documenting of the IFOTA design. Appendix B 
provides key Use Case, Entity Relationship, and Class diagrams for the system. This 
documentation has been delivered in electronic format under separate cover. 


5.1.1 Advanced Technical Features 

The workstation/presentation tier uses the Eclipse RCP. The Eclipse RCP is built on the 
extendable Open Services Gateway Initiative (OSGI) service execution framework. The 
extendibility of this framework permits the use of extension points to provide a means for 
plug-ins/modules to insert capability at application defined points, referred to as 
extension points. IFOTA developed a node extension point and an exporter extension 
point. The node extension point was used to permit the introduction of new plan types, 
such as a refined PYSOP plan type or a custom military deception plan type. All plan 
types built within IFOTA use the node extension point to incorporate their plan type 
functions into the overarching IFOTA platform. The exporter extension point is used to 
incorporate plan product generators. The two plan product generators included in IFOTA 
are the PowerPoint presentation generator and the HTMF generator. The PowerPoint 
presentation product generator (plan exporter) wraps Component Object Model (COM) 
functionality exposed by the Microsoft PowerPoint application libraries to create 
presentations. Figure 15 illustrates the IFOTA client stack. 


Eclipse Provided Plug-ins IFOTA Plug-ins 


Eclipse Rich Client Platform 

Microba 

(Date Picker) 

Deconfliction 

Wizard 

JUNG 

(Scenario Editor) 

RCP Optional 
(Help, Forms, Update, etc) 

Jaret Time Bar 

(Gantt Chart) 

Swabunga 

(Spellchecker) 

IFOTA Counter 
Intelligence Plan 

Generic Workbench 
(Editors, Views, Perspectives) 

System 

Resources 

IFOTA Exporters 

(PowerPoint, HTML) 

IFOTA Military 
Deception Plan 

IFOTA Public 
Affairs Plan 

JFace 

(TableViewer, etc) 

Platform Runtime 
(System Plug-ins) 

Jawin 

(Windows Native 
Interface) 

IFOTA Operational Security Plan 

SWT 

(button, Table, etc.) 

OSGi 

(On demand classloading) 

IFOTA Rich Client 

(IFOTA Visualizations) 

IFOTA 

Psychological 
Operations Plan 


Figure 15. Client stack 


IFOTA architecture included an advanced locking mechanism. It enabled users to specify 
locks onto planning elements to restrict editing by planning collaboration users, ideally 
when they needed to modify the plan. The locking mechanism worked based on a node 
level (as contrasted by the node property level or the whole plan locking level). JMS was 
used to propagate locking status changes among the collaboration users. J2EE Timers 
were used to force lock releases upon client inactivity for an extended period. 


32 

Approved for public release; distribution unlimited. 





















































5.1.2 Rich Client Integration 

Since the client leveraged the Eclipse RCP, the features and function of IFOTA can be 
integrated into other Eclipse RCP applications fairly easily. This is based on the fact 
IFOTA client itself being just a set of plug-ins sitting on the underlying Eclipse RCP. A 
proof-of-concept integration effort included a research and analysis toolkit integration 
with a 3D visualization application. 


5.1.3 Training Environment Configuration 

For the support of IFOTA use in training environments, a student number authentication 
system was implemented. A role selection mechanism was also used to define the student 
accessible aspects of the software, for example a student acting as a PSYOP planner 
would select the PSYOP planner role. The system would then restrict the student from 
taking part in activities not performed by this role, such as creating military deception 
plans. A special, super-user role was given to the authenticated instructor users. This role 
permitted instructor plan commenting activities, RFI responding activities, lesson book 
management, etc. The IFOTA server based architecture and asynchronous messaging 
enabled a distributed user collaboration environment. The Table 2 lists IFOTA software 
features. 


Table 2. IFOTA Software Features 


IFOTA Software Feature List 

• Plan Deconfliction 

• Threaded Discussions/Instructor Chat 

• Discussion integrated into Plan View 

• Comments applied onto step 

• Wizards Checklists/Step Flags 

• Modules 

• Drag and Drop Palette 

• Spell check capability 

• Gantt Chart/Time Series Plan View/Editor 

• Hierarchy Plan Relationship View/Editor 

• Plan Status Indicators 

• Dynamic Overview Reports 

• Plan locking 

• Plan creation based on plan type wizards 

o PSYOP planning 

o MD planning 

o OPS EC planning 

o PA Planning 

o Cl Planning 
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5.1.4 IFOTA System Requirements 

In its IFOTA 4.0 configuration, IFOTA requires Java JRE version 1.5 or greater, an 
Oracle lOg database, and a Windows 2000 or XP Operating System. 


6.0 DISCUSSION: WARFIGHTER ANALYSIS WORKSHOPS 

IFOTA was demonstrated at the 2007 JFCOM Information Operations Planning 
Capability-Joint (IOPC-J) Warfighter Analysis Workshop, the 2008 Air Combat 
Command Warfighter Analysis of Innovative Technologies and Concepts (WAIT-C) 
interactive technology demonstration and at the 2006 and 2007 Phoenix Challenges. The 
general response was enthusiastic, as the tool’s collaborative nature, its structured 
planning methodology and deconfliction tool, and its analysis framework and rationale 
documentation were all viewed as integral to coordinating joint planning efforts. 

At the JFCOM IOPC-J Warfighter Analysis Workshop, IFOTA was reviewed by 
representatives from Air Force’s 7 th IOF, the Texas National Guard’s 49th IO Group, the 
Army’s 1 st IO Command Tech Integration, and the Navy Information Operations 
Command ‘s (NIOC MD) Information Operations Strategy and Policy group. Capabilities 
queries involved addition of a Counterpropaganda module and a multilingual user 
interface. The WAIT-C demonstration allowed both AOC strategy planners and IO 
specialists to interact with IFOTA. Potential users from both groups were equally 
enthusiastic about the structured method and the documentation of the planner’s 
rationale—a critical feature when working collaboratively. Other features that received 
positive response were embedded methods for weighting efforts and anticipating 
resistance/cooperation. The scenario-based training was considered an effective way to 
maintain readiness among teams with differing levels of expertise. 

Phoenix Challenge Conferences are DoD-sponsored events that bring government, 
industry, academia, and coalition partners together to consider IO challenges and 
solutions. IO community representatives share information on and discuss ramifications 
of the latest IO policies, strategies, technologies, processes, legal issues, human capital, 
force structure, and education and training. The response at Phoenix Challenge 2006 and 
2007 was positive. IO professionals expressed concerns with development of MOEs and 
MOPs for IO and IFO; tools, such as IFOTA, that prompt MOE and MOP development 
are desired. The scenario-based training and checklist guided methodology were well 
received. 

The desirability of extending IFOTA to incorporate the full range of IO planning was 
discussed by IO representatives at both the Warfighter Analysis Workshops and the 
Phoenix Challenges. IO tools, such as IOPC-J, are future efforts. While there is a desire 
to “train as we fight” (i.e., use deployed tools such as Information Warfare Planning 
Capability, IWPC), there is also an acknowledgment that the current tools do not 
completely fill IO planner needs, and what will be available in the future cannot be 
considered helpful today. The IO community seeks solutions that both support their 
unique planning needs and integrate well with traditional planning methods. The 39 th 
IOS, in its well-considered requirements expression, sought to make IFOTA the bridge. 
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7.0 CONCLUSION/RECOMMENDATIONS 


IFOTA 4.0 is a working prototype for planning and documenting IFO in a training 
environment. Based on specific requests from the 39 th IOS IOIC course instructors, 
IFOTA is a scenario-based collaborative training environment featuring drag-and-drop 
plan building supplemented by a reconfigurable (data-driven) Visual Checklist that 
guides 10 students and practitioners through the textbook methodology (including 
deconfliction) for PSYOP, MD, OPSEC, PA and Cl disciplines. A built-in operational 
taxonomy provides decision support for plan development. A dynamically updated Gantt 
Chart (Time-Series View) provides a temporal window on plan sequencing. A built-in 
dual PowerPoint/HTML briefing generator saves time and effort creating decision briefs. 
Instructor features include a Lesson Plan/Course Repository, Maintenance of Acronyms 
and Definitions, Links to External Planning Resources, RLI simulation, and printable 
Quick Look Books. Table 3 shows the primary requirement to capability mapping for 
ILOTA. 


Table 3. Requirement to Capability Mapping 


Requirement 

IFOTA Capability 

Open architecture 

Open architecture built around Eclipse RCP, J2EE, JBOSS 

Helps planners develop 
viable 10 options 

Decision aids and built-in taxonomy supported by data-driven 
Visual Checklist reinforces strategy-to-task planning 
methodology 

Collaborative capabilities 

I2EE with locking mechanism allows multiple clients to work 
in the same scenario simultaneously across geographical 
locations while enabling real-time data sharing between users 

Deconfliction 

Integrated plans can be deconflicted using IFOTA’s plug-in 
wizard 

Plan-to-assessment 
approach / Assessment 
Planning 

MOEs and MOPs incorporated into plan; tool allows for 
iterative planning process to allow assessment of plans upon 
completion; can annotate intel assessment 

Break down objectives 

IFOTA allows users to break objectives and Commander’s 
intent into tasks, subtasks, targets, target audience analysis, 
desired effects, MOPs, MOEs, associated MOE indicators 

Provide COCOMS the 
capability to plan and 
assess integrated 10 plans 
through manual means 

Built-in PowerPoint generator and HTML export tool for 
generating manual documents to enhance communications 

CO A Development 

Ability to understand target audience, generate possible 
effects-based actions, and select ultimate planning requirement 

Visualizations 

Drag and drop scenario development with associated pull¬ 
down and right-click menus; time-series views, ability to 
develop additional visualizations leveraging Eclipse RCP and 
IFOTA IFO-specific data 

Strategy-to-Task 

Planning 

Data-driven Visual Checklist enhances user effectiveness by 
allowing non-linear progression while enforcing completion of 
strategy-to-task planning 
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Time Synchronization 

Gantt chart/time-series view built in 

Reachback Support 

Connectivity to CIA World Factbook, Reardon Group (or 
current provider), Other External Finks 

Modular and Scalable 

All Modules (PSYOP, PA, MD, Cl, OPSEC, Instructor) can be 
turned on/off; additional modules can be easily plugged in 


The uniformly positive responses to IFOTA suggest that the 39 th IOS has defined the 10 
planning support needs well. Extension of IFOTA to incorporate all of the 10 disciplines 
is needed to complete it; due to the great interest in and need for effective 10 planning 
tools, it is highly recommended that IFOTA be reviewed for inclusion in the next 10 
system of record. Although DoD software development is moving more toward thin- 
client applications, with the advances in support to service-oriented architectures, IFOTA 
can be relatively easily rethought to provide a similar level of support in a web-based 
application. In a thin client format, the IFOTA functions would fill a gap in cognitive- 
based tool support for 10 training. It will benefit the 10 community if the insights of 
those 10 experts who contributed to IFOTA’s requirements development are not lost. It 
will benefit the 10 community if the collaborative support provided through IFOTA’s 
concept of tracking plan rationale is retained. 
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The following requirements were derived from discussions with the 39 th IOS and selected 
subject matter experts and from official training and doctrine documents. Requirements 
were prioritized and implemented incrementally as IFOTA was developed. Note that not 
all requirements were approved for funding during the period of performance. They are 
included here to illustrate the features that were considered desirable. 


ID 

Requirement 

Type 

Requirement Statement 

1 

Module: Help 
System 

The Help System shall provide directions on how to use IFOTA 

2 

Module: Help 
System 

The Help System shall provide links to support material provided by the 
39th IOS (i.e., URLs on JWICS, SIPRNet, etc.) The instructors will 
add/update this list via the Instructor Module. 

3 

Module: Help 
System 

The Help System shall provide definitions of all terms used in the 
software. The instructors will add/update the definitions list via the 
Instructor Module. 

4 

Module: Help 
System 

The Help System shall provide examples of each write-in box (i.e., 
justification/citation boxes) 

5 

Module: Help 
System 

The Help System shall provide contextual help for each user activity (i.e., 
right-click or click-question-mark-then-click-item-you-want-help-on) 

6 

Module: Help 
System 

The Help System shall include explanations for all menu items and 
buttons. 

7 

Module: Help 
System 

The Help System shall identify names and functions of all software panes 
and frames. Use title bars on all windows. 

8 

Module: Help 
System 

The Help System shall identify how to regain closed software panes and 
frames. 

9 

Module: Help 
System 

The Help System shall provide instruction on how to customize the 
toolbar. 

10 

Module: Help 
System 

The Help System shall provide instruction on how to revert the toolbar 
back to standard. 

11 

Module: Help 
System 

The Help System shall include compilations of all individual contextual 
help entries. (In other words, everything that's included in the contextual 
help will also be included in the definitions/acronyms, index, etc. of the 
actual full-blown Help system. 

12 

Module: Help 
System 

The Help System shall contain explanations for all algorithms. 

13 

Module: Help 
System 

The Help System shall contain explanations for how to deconflict tasks. 

14 

Module: Help 
System 

The Help System shall contain explanations for how to use results 
displays. 
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15 

Module: Help 
System 

The Help System shall contain explanations for how to alter influence 
factors to change algorithm results. 

16 

Module: Help 
System 

The IFOTA shall provide a platform-independent Help System 

17 

Module: Help 
System 

The IFOTA shall allow Help to remain onscreen while the user is working 
in the IFOTA program. (Perhaps a floating window that can be closed.) 

18 

Module: Help 
System 

The IFOTA Help screens shall be dockable/undockable 

19 

Module: Help 
System 

The IFOTA Help screens shall be resizable 

20 

Module: Help 
System 

The IFOTA shall allow the user to print Help entries (without having to 
print the entire help system) 

21 

Module: Help 
System 

The IFOTA shall provide contextual help at all decision points 

22 

Module: Help 
System 

The IFOTA shall provide contextual help in the form of "on-demand" 
popups 

23 

Module: Help 
System 

The IFOTA shall access dialog box contextual help using a question 
mark icon 

24 

Module: Help 
System 

The IFOTA shall provide contextual help in the form of text definitions for 
course vocabulary items 

25 

Module: Help 
System 

The IFOTA shall highlight text entries that have associated contextual 
help, if available. 

26 

Module: Help 
System 

The IFOTA shall access highlighted contextual help items by 
doubleclicking on highlighted text 

27 

Module: Help 
System 

The Help System shall remain open until it is manually closed by the 
user. 

28 

Module: Help 
System 

The Help System shall instruct the user how to navigate within a scenario 

29 

Module: Help 
System 

The Help System shall include selected sections of each instructors' 
lesson notes (to be input by the 39th IOS). 

30 

Module: Help 
System 

The Help System shall be navigable by hyperlink to additional help 
topics. 

31 

Module: Help 
System 

The Help System shall provide a search feature. 


A-3 

Approved for public release; distribution unlimited. 




32 

Module: 

Instructor 

The Instructor Module shall allow the instructor to view student activities 
in near real-time as the student's work is saved. 

33 

Module: 

Instructor 

An Instructor Module shall have a separate login feature. 

34 

Module: 

Instructor 

The Instructor Module shall have a separate interface. 

35 

Module: 

Instructor 

The Instructor Module shall allow the instructor to enter new data into the 
databases. 

36 

Module: 

Instructor 

The Instructor Module shall allow the instructor to change data in the 
databases. 

37 

Module: 

Instructor 

The IFOTA shall allow instructors to view students' work in real time 

38 

System: 

General 

The IFOTA shall associate a workgroup identification and a student 
identification with each saved scenario 

39 

System: 

General 

The IFOTA shall capture justifications and references for student's work 

40 

Module: 

Instructor 

The IFOTA shall allow instructors to modify (add/delete/change) the 
student's plan and save modifications to the database. 

41 

Module: 

Instructor 

The IFOTA shall allow the instructor to notify the student that the 
instructor has annotated the student's work 

42 

Module: 

Instructor 

The IFOTA shall allow the student to transfer to the modified file 

43 

Module: 

Instructor 

The IFOTA shall capture grades for student work 

44 

Module: 

Instructor 

The IFOTA shall capture student actions in a readable log file 

45 

Module: 

Instructor 

The IFOTA shall permit instructors to create scenario templates 

46 

Module: 

Instructor 

The IFOTA shall permit instructors to modify scenario templates 

47 

Module: 

Instructor 

The IFOTA shall allow instructors to modify scenario data 

48 

Module: 

Instructor 

The IFOTA shall allow instructors/staff to create new scenarios 
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49 

Module: 

Instructor 

The IFOTA shall provide a method for testing students 

50 

Module: 

Instructor 

The IFOTA shall provide a method for annotating tests 

51 

Module: 

Instructor 

The IFOTA shall provide a method for calculating grades for each test or 
exercise 

52 

Module: 

Instructor 

The IFOTA shall capture summary/final grades 

53 

Module: 

Instructor 

The Instructor Module shall allow the instructor to delete data from the 
databases. 

54 

Module: MD 

A module shall be built to encompass the planning aspect of Military 
Deception (MD). 

55 

Module: MD 

The IFOTA shall provide example MD-specific tactical support tasks 

56 

Module: MD 

The IFOTA shall allow the user to select multiple tactical supporting 
task(s) for each tactical task 

57 

Module: MD 

The IFOTA shall allow the user to enter their own tactical supporting 
tasks 

58 

Module: MD 

The IFOTA shall provide space to insert measures of performance 
(MOPs) for each tactical supporting task 

59 

Module: MD 

The IFOTA shall provide example MOPs 

60 

Module: MD 

The IFOTA shall link to MD supporting references (simulating reachback 
and SIPRNET) 

61 

Module: RFI 

The IFOTA shall capture RFIs needed to perform assessment 

62 

Module: MD 

The IFOTA shall pop up deconfliction/coordination screen after tactical 
support task(s) are selected 

63 

Module: MD 

The IFOTA shall allow the user to identify target audience 

64 

Module: MD 

The IFOTA shall pop up deconfliction/coordination screen after target 
audience is selected 

65 

Module: MD 

The IFOTA shall allow the user to input current perception 
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66 

Module: MD 

The IFOTA shall prompt the user to select perception management 
objective (create/change/maintain) 

67 

Module: MD 

The IFOTA shall allow the user to input desired perception (descriptive 
action title) 

68 

Module: MD 

The IFOTA shall allow the user to input detailed storyline 

69 

Module: MD 

The IFOTA shall pop up deconfliction/coordination screen after storyline 
is developed 

70 

Module: MD 

The IFOTA shall allow the user to select from a dropdown list of means 

71 

Module: MD 

The IFOTA shall categorize means as Administrative, Technical, or 
Physical 

72 

Module: MD 

The IFOTA shall pop up deconfliction/coordination screen after means 
are selected 

73 

Module: MD 

The IFOTA shall allow the user to input "Special Actions" 

74 

Module: MD 

The IFOTA shall capture justification for target audience selection 

75 

Module: MD 

The IFOTA shall capture justification for perception management plan 
(desired perception, story, and means) 

76 

Module: MD 

The IFOTA shall allow the user to describe the action termination plan 

77 

Module: MD 

The IFOTA shall allow the user to identify termination cue and 
termination cover story (as appropriate) 

78 

Module: MD 

The IFOTA shall allow the user to identify termination authority 

79 

Module: MD 

The IFOTA shall allow the user to identify what information can be 
released/when 

80 

Module: MD 

The IFOTA shall allow the user to identify what conduits need to be 
terminated/continued 

81 

Module: MD 

The IFOTA shall capture justification for action termination plan 

82 

Module: MD 

The IFOTA shall display an Event Schedule based on Joint Pub 3-58 
plus Location/Target 


A-6 

Approved for public release; distribution unlimited. 




83 

Module: MD 

The IFOTA shall pop up deconfliction/coordination screen after the Event 
Schedule is created 

84 

Module: RFI 

The IFOTA shall capture collection requests (RFIs) for course of action 
assessment (feedback) 

85 

Module: MD 

The IFOTA shall capture/display feedback 

86 

Module: MD 

The IFOTA shall display feedback in a table similar to the Event 

Schedule (ID#, Objective, Time, Action/Means, Unit, Location/Target, 
feedback) 

87 

Module: MD 

The IFOTA shall distinguish feedback as MOP (did the story get out) and 
MOE (did the target respond as desired) 

88 

Module: MD 

The IFOTA shall provide a MOPs chart listing Event, Unit, Scheduled 

DTG, % Completed, Feedback channels 

89 

Module: MD 

The IFOTA shall provide a termination assessment 

90 

Module: MD 

The IFOTA shall provide an MD summary relating MD tasks and MOPs 
to tactical tasks/MOPS and tactical objectives/MOEs 

91 

Module: MD 

The IFOTA shall permit the student to deconflict across planning cycle 
and operational phases 

92 

Module: 

OPSEC 

The IFOTA shall provide example OPSEC-specific tactical support tasks 

93 

Module: 

OPSEC 

The IFOTA shall allow the user to select multiple tactical support task(s) 
for each tactical task 

94 

Module: 

OPSEC 

The IFOTA shall allow the user to enter their own tactical support tasks 

95 

Module: 

OPSEC 

The IFOTA shall provide space to insert MOPs for each tactical support 
task 

96 

Module: 

OPSEC 

The IFOTA shall give an example measure of performance (MOP) 

97 

Module: 

OPSEC 

The IFOTA shall pop up deconfliction/coordination screen after tactical 
support task(s) are selected 

98 

Module: 

OPSEC 

The IFOTA shall link to OPSEC supporting references (simulating 
reachback and SIPRNET) 

99 

Module: RFI 

The IFOTA shall capture RFIs needed to perform assessment 
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100 

Module: 

OPSEC 

The IFOTA shall allow the user to identify Critical Information (subset of 
Essential Element of Friendly Information - EEFIs) from a dropdown list 

101 

Module: 

OPSEC 

The IFOTA shall allow the user to enter Critical Information items 

102 

Module: 

OPSEC 

The IFOTA shall capture justification for Critical Information identification 

103 

Module: 

OPSEC 

The IFOTA shall allow the user to identify target audience 

104 

Module: 

OPSEC 

The IFOTA shall pop up deconfliction/coordination screen after target 
audience is selected 

105 

Module: 

OPSEC 

The IFOTA shall allow the user to identify OPSEC measures from a 
dropdown list 

106 

Module: 

OPSEC 

The IFOTA shall allow the user to identify interactions and unintended 
consequences from employment of OPSEC measures 

107 

Module: 

OPSEC 

The IFOTA shall allow the user to develop OPSEC primary and 
secondary countermeasures 

108 

Module: 

OPSEC 

The IFOTA shall allow the user to identify MOPs and MOEs 

109 

Module: RFI 

The IFOTA shall capture RFIs needed to perform assessment 

110 

Module: 

OPSEC 

The IFOTA shall capture justification for the OPSEC plan 

111 

Module: 

OPSEC 

The IFOTA shall pop up deconfliction/coordination screen after OPSEC 
COA is selected 

112 

Module: 

OPSEC 

The IFOTA shall allow the user to identify adversary Threats from a 
dropdown list 

113 

Module: 

OPSEC 

The IFOTA shall allow the user to enter Threat types 

114 

Module: 

OPSEC 

The IFOTA shall allow the user to identify OPSEC Indicators from a 
dropdown list 

115 

Module: 

OPSEC 

The IFOTA shall allow the user to enter OPSEC Indicators 

116 

Module: 

OPSEC 

The IFOTA shall allow the user to identify and analyze Vulnerabilities 
from a dropdown list 
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117 

Module: 

OPSEC 

The IFOTA shall allow the user to enter Vulnerabilities 

118 

Module: 

OPSEC 

The IFOTA shall capture justification of the way and the circumstances in 
which the Indicator is a Vulnerability 

119 

Module: 

OPSEC 

The IFOTA shall allow the user to assess risk using an algorithm to factor 
in levels of Threat, Vulnerability and Impact 

120 

Module: 

OPSEC 

The IFOTA shall use scales ( e.g., 5-pt scale) to capture user 
assessments for threat, vulnerability, and impact 

121 

Module: 

OPSEC 

The IFOTA shall provide a risk summary 

122 

Module: 

OPSEC 

The IFOTA shall allow the user to provide a cost/benefit analysis 

123 

Module: 

OPSEC 

The IFOTA shall capture collection requests for course of action 
assessment (feedback) 

124 

Module: 

OPSEC 

The IFOTA shall provide an OPSEC summary relating OPSEC tasks and 
MOPs to tactical tasks/MOPS and tactical objectives/MOEs 

125 

Module: 

OPSEC 

The IFOTA shall permit the student to deconflict across planning cycle 
and operational phases 

126 

Module: PA 

A module shall be built to encompass the planning component of PA. 

127 

Module: PA 

The IFOTA shall provide example PA-specific tactical support tasks 

128 

Module: PA 

The IFOTA shall allow the user to select multiple tactical support task(s) 
for each tactical task 

129 

Module: PA 

The IFOTA shall allow the user to enter own tactical support tasks 

130 

Module: PA 

The IFOTA shall provide space to insert MOPs for each tactical support 
task 

131 

Module: PA 

The IFOTA shall give an example measure of performance (MOP) 

132 

Module: RFI 

The IFOTA shall capture RFIs needed to perform assessment 

133 

Module: PA 

The IFOTA shall pop up deconfliction screen after tactical support task(s) 
are selected 
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134 

Software: 

General 

The IFOTA shall capture/display unifying themes 

135 

Module: PA 

The IFOTA shall allow the user to enter own message for each plan 

136 

Module: PA 

The IFOTA shall pop up a deconfliction screen after messages and 
themes are selected 

137 

Module: PA 

The IFOTA shall capture justification for theme/symbol selection 

138 

Module: PA 

The IFOTA shall link to PA supporting references 

139 

Module: PA 

The IFOTA shall allow the user to identify Critical Information (subset of 
EEFIs) from a dropdown list 

140 

Module: PA 

The IFOTA shall allow the user to enter Critical Information items 

141 

Module: PA 

The IFOTA shall capture justification for selection of Critical Information 
items 

142 

Module: PA 

The IFOTA shall capture whether the student is in proactive or reactive 
mode 

143 

Module: PA 

The IFOTA shall capture whether the student is planning a passive or 
active information campaign 

144 

Module: PA 

The IFOTA shall capture justification for decision to react/not react 

145 

Module: RFI 

The IFOTA shall generate RFIs needed to fill knowledge gap 

146 

Module: PA 

The IFOTA shall allow the user to select a target audience 

147 

Module: PA 

The IFOTA shall allow the user to enter a target audience 

148 

Module: PA 

The IFOTA shall capture justification for target audience selection 

149 

Module: PA 

The IFOTA shall pop up deconfliction screen after target audience is 
selected 

150 

Module: PA 

The IFOTA shall provide a dropdown list of example target actions 
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151 

Module: PA 

The IFOTA shall allow the user to enter own target action 

152 

Module: PA 

The IFOTA shall allow the user to select/enter target action 

153 

Module: PA 

The IFOTA shall capture Situation Description and response justification 
(Information, T/F, Source, Response, Rationale) 

154 

Module: PA 

The IFOTA shall pop up deconfliction screen after response is selected 

155 

Module: PA 

The IFOTA shall capture Dissemination Plan (Response, Means, 

Methods, Timing) 

156 

Module: PA 

The IFOTA shall pop up deconfliction screen after response plan is 
delineated 

157 

Module: PA 

The IFOTA shall capture MOPs and MOEs 

158 

Module: RFI 

The IFOTA shall capture RFIs needed to perform assessment 

159 

Module: PA 

The IFOTA shall capture simulated response effectiveness (Response, 
Measures of Effectiveness) 

160 

Module: PA 

The IFOTA shall provide a PA summary relating PA tasks and MOPs to 
tactical tasks/MOPS and tactical objectives/MOEs 

161 

Module: PA 

The IFOTA shall permit the student to deconflict across planning cycle 
and operational phases 

162 

Module: 

PSYOP 

The IFOTA shall provide example PSYOP-specific tactical support tasks 

163 

Module: 

PSYOP 

The IFOTA shall allow the user to select multiple tactical support task(s) 
for each tactical task 

164 

Module: 

PSYOP 

The IFOTA shall allow the user to enter own tactical support tasks 

165 

Module: 

PSYOP 

The IFOTA shall provide space to insert MOPs for each tactical support 
task 

166 

Module: 

PSYOP 

The IFOTA shall give an example measure of performance (MOP) 

167 

Module: RFI 

The IFOTA shall capture RFIs needed to perform assessment 
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168 

Module: 

PSYOP 

The IFOTA shall pop up deconfliction screen after tactical support task(s) 
are selected 

169 

Module: 

PSYOP 

The IFOTA shall capture/display themes and symbols for each branch 

170 

Module: 

PSYOP 

The IFOTA shall allow the user to enter own message and theme for 
each plan 

171 

Module: 

PSYOP 

The IFOTA shall pop up a deconfliction screen after messages and 
themes are selected 

172 

Module: 

PSYOP 

The IFOTA shall capture justification for theme/symbol selection 

173 

Module: 

PSYOP 

The IFOTA shall list (or link to) target audiences and specific 
political/sociocultural and demographic information 

174 

Module: 

PSYOP 

The IFOTA shall allow the user to select a target audience 

175 

Module: 

PSYOP 

The IFOTA shall allow the user to enter a target audience 

176 

Module: 

PSYOP 

The IFOTA shall capture justification for target audience selection 

177 

Module: RFI 

The IFOTA shall generate RFIs needed to fill knowledge gap 

178 

Module: 

PSYOP 

The IFOTA shall pop up deconfliction screen after target audience is 
selected 

179 

Module: 

PSYOP 

The IFOTA shall provide a dropdown list of example target actions 

180 

Module: 

PSYOP 

The IFOTA shall allow the user to enter own target action 

181 

Module: 

PSYOP 

The IFOTA shall allow the user to select/enter target action 

182 

Module: Help 
System 

The IFOTA shall provide example MOPs/MOEs 

183 

Module: 

PSYOP 

The IFOTA shall allow the user to enter MOEs 

184 

Module: 

PSYOP 

The IFOTA shall capture collection requests for target action assessment 
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185 

Module: 

PSYOP 

The IFOTA shall capture justification for how target action supports 
messages/themes/symbols 

186 

Module: 

PSYOP 

The IFOTA shall pop up deconfliction screen after target action is 
selected 

187 

Module: 

PSYOP 

The IFOTA shall list target audience/target action specific 
situational/cultural factors 

188 

Module: 

PSYOP 

The IFOTA shall provide default selection of applicable 
situational/cultural factors (from embedded knowledge) 

189 

Module: 

PSYOP 

The IFOTA shall allow the user to modify applicable situational/cultural 
factors 

190 

Module: 

PSYOP 

The IFOTA shall allow the user to enter own situational/cultural factors 

191 

Module: 

PSYOP 

The IFOTA shall list possible situational/cultural conditions (from 
embedded knowledge) 

192 

Module: 

PSYOP 

The IFOTA shall allow the user to select applicable conditions 

193 

Module: 

PSYOP 

The IFOTA shall allow the user to enter new conditions 

194 

Module: 

PSYOP 

The IFOTA shall capture user's prioritization (ranking) of conditions 
(vulnerabilities) 

195 

Module: 

PSYOP 

The IFOTA shall capture user's relative weighting of conditions 
(susceptibilities) 

196 

Module: 

PSYOP 

The IFOTA shall capture user's Red/Yellow/Green (stoplight metaphor) 
assessment 

197 

Module: 

PSYOP 

The IFOTA shall allow the user to skip SMART model and go directly to 
delivery method selection 

198 

Module: 

PSYOP 

The IFOTA shall collect SMART model decision criteria 

199 

Module: 

PSYOP 

The IFOTA shall use scales to capture user assessments required for 
SMART model 

200 

Module: RFI 

The IFOTA shall generate RFIs needed to fill SMART criteria knowledge 
gap 

201 

Module: 

PSYOP 

The IFOTA shall display SMART model evaluations 
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202 

Module: 

PSYOP 

The IFOTA shall allow the user to modify SMART model inputs and rerun 
algorithm 

203 

Module: 

PSYOP 

The IFOTA shall provide an example list of delivery methods 

204 

Module: 

PSYOP 

The IFOTA shall allow the user to select/write a delivery method 

205 

Module: 

PSYOP 

The IFOTA shall pop up deconfliction screen after delivery method is 
selected 

206 

Module: 

PSYOP 

The IFOTA shall provide a PSYOP summary relating PSYOP tasks and 
MOPs to tactical tasks/MOPs and tactical objectives/MOEs 

207 

Module: 

PSYOP 

The IFOTA shall capture collection requests for course of action 
assessment 

208 

Module: 

PSYOP 

The IFOTA shall permit the student to deconflict across planning cycle 
and operational phases 

209 

Software: 

General 

The IFOTA shall include icons to customize the tool bar to include any 
function 

210 

Software: 

General 

The IFOTA shall open each new work session with the JWICS regional 
commands map 

211 

Software: 

General 

The IFOTA shall display the scenarios by region (and country) when you 
click on the map 

212 

Software: 

General 

The IFOTA shall link to basic political and sociocultural information for 
each country 

213 

Software: 

General 

The IFOTA shall allow the user to select the scenarios associated with a 
single country 

214 

Software: 

General 

The IFOTA shall display a map for each country 

215 

Software: 

General 

The IFOTA shall link to demographic, political and sociocultural 
information for each distinct region within the country 

216 

Software: 

General 

The IFOTA shall open each scenario and immediately display the 
summary sheet 

217 

Software: 

General 

The IFOTA shall provide a list of combined operational tasks organized 
by service and operational phase 

218 

Software: 

General 

The IFOTA shall provide example success indicators for 
each operational objective 
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219 

Software: 

General 

The IFOTA shall allow the user to select/write multiple 
operational objective(s) and success indicators 

220 

Software: 

General 

The IFOTA shall provide an example list of Air Force tactical objectives 
organized by service it supports 

221 

Software: 

General 

The IFOTA shall provide example measures of effectiveness (MOEs) for 
each tactical objective 

222 

Software: 

General 

The IFOTA shall allow the user to select/write multiple tactical objectives 

223 

Software: 

General 

The IFOTA shall allow the user to select/write MOEs for each objective 

224 

Software: 

General 

The IFOTA shall provide an example list of Air Force tactical tasks 
organized by service it supports 

225 

Software: 

General 

The IFOTA shall provide example measures of performance (MOPs) for 
each tactical task 

226 

Software: 

General 

The IFOTA shall allow the user to select/write multiple tactical tasks 

227 

Software: 

General 

The IFOTA shall allow the user to select/write MOPs for each task 

228 

Software: 

General 

The IFOTA shall allow the user to enter own tactical tasks 

229 

Software: 

General 

The IFOTA shall allow the user to enter own MOPs 

230 

Software: 

General 

The IFOTA shall show task branches 

231 

Software: 

General 

The IFOTA shall allow the user to create task branches 

232 

Software: 

General 

The IFOTA scenario shall identify the current planning stage 

233 

Software: 

General 

The IFOTA scenario shall identify the current operational phase 

234 

Software: 

General 

The IFOTA shall have a status screen that summarizes current status for 
each module 

235 

Software: 

General 

The IFOTA shall display current information from each module on the 
summary screen(s) 
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236 

Software: 

General 

The IFOTA shall display information from each module from the following 
fields on the summary screen(s): operational objective, SI, tactical 
objective, MOE, tactical task, MOP, tactical support task, MOP, target 
audience, target action, rationale, link to synchronization matrix 

237 

Software: 

General 

The IFOTA shall pull summary information from the corresponding data 
entry fields in each individual module 

238 

Software: 

General 

The IFOTA shall update the summary plan automatically whenever any 
data that feed the summary fields change 

239 

Software: 

General 

The IFOTA shall have a deconfliction version of the summary screen with 
checkboxes to indicate deconfliction has been accomplished 

240 

Module: 

Deconfliction 

The IFOTA shall have a deconfliction/coordination feature that prompts 
the user to deconflict/coordinate with other disciplines 

241 

Module: 

Deconfliction 

The IFOTA shall display the deconfliction screen whenever the student 
reaches an identified deconfliction point in the process 

242 

Module: 

Deconfliction 

The IFOTA shall have a deconfliction button that brings up the 
summary/deconfliction screen at user command 

243 

Module: 

Deconfliction 

The IFOTA shall use the status screen for the deconfliction/coordination 
function 

244 

Module: 

Deconfliction 

The IFOTA shall display checkboxes by each deconfliction action in the 
deconfliction function 

245 

Module: 

Deconfliction 

The IFOTA shall timestamp each deconfliction/coordination action 

246 

Module: 

Deconfliction 

The IFOTA shall allow the student to enter the deconfliction action 
whenever the student fills in a deconfliction checkbox 

247 

Module: 

Deconfliction 

The IFOTA shall allow the student to enter the deconfliction rationale 
whenever the student fills in a deconfliction checkbox 

248 

Module: 

Deconfliction 

The IFOTA shall not allow the student to proceed until the student has 
checked each box and entered text in each action description text field 

249 

Software: 

General 

The IFOTA shall permit the user to manage multiple windows 

250 

Software: 

General 

The IFOTA shall allow the user to tile windows horizontally and vertically 

251 

Software: 

General 

The IFOTA shall allow the user to resize all windows 

252 

Software: 

General 

The IFOTA shall allow the user to move all windows 
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253 

Software: 

General 

The IFOTA shall allow the user to close all windows 

254 

Software: 

General 

The IFOTA shall allow the user to minimize all windows 

255 

Software: 

General 

The IFOTA shall allow the user to move freely between windows 

256 

Software: 

General 

The IFOTA shall include a toggle capability to enlarge window in which 
student is working 

257 

Software: 

General 

The IFOTA shall allow the user to tab between windows 

258 

Module: RFI 

The IFOTA shall provide a Coliseum RFI template 

259 

Module: RFI 

The IFOTA shall provide the means to make other RFI templates 

260 

Module: RFI 

The IFOTA shall allow the user to draft RFIs to obtain information 
necessary to complete scenario tasks 

261 

Module: RFI 

The IFOTA shall capture RFIs for instructor 

262 

Module: RFI 

The IFOTA shall simulate tracking RFI status 

263 

Module: RFI 

The IFOTA shall allow the user to create assessment collection RFIs 

264 

System: 

General 

IFOTA shall be designed to work in a secure environment. 

265 

System: 

General 

IFOTA shall be designed to work in a secure environment. 

270 

System: 

General 

The IFOTA shall store login information. 

271 

Software: 

General 

All text boxes shall have an auto-wrap feature. 

272 

Software: 

General 

All text boxes shall have a scroll-bar feature that becomes active when 
necessary. 

273 

Software: 

General 

The IFOTA shall have a Windows look and feel 
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274 

Software: 

General 

The IFOTA shall have a main menu with submenus and toolbar with icon 
buttons 

275 

Software: 

General 

The IFOTA shall use portions of the DIICOE and Xerox usability 
standards as guidelines for software development. 

276 

Software: 

General 

The IFOTA shall open to a blank window 

277 

Software: 

General 

The IFOTA shall provide a scenario chooser to display existing scenarios 
for selection 

278 

Software: 

General 

The IFOTA shall provide scenario search capability 

279 

Software: 

General 

The IFOTA shall provide a login function 

280 

Software: 

General 

The IFOTA shall allow the user to open existing scenarios 

281 

Software: 

General 

The IFOTA shall allow the user to create new scenarios 

282 

Software: 

General 

The IFOTA shall allow the user to save their work to the database 

283 

Software: 

General 

The IFOTA shall allow the user to modify their work according to 
permissions 

284 

Software: 

General 

The IFOTA shall ensure students can't overwrite scenarios from library 

285 

Software: 

General 

The IFOTA shall allow students to modify (add/delete/change) their own 
work 

286 

Functionality: 

Print 

The IFOTA shall allow the user to print whole scenarios 

287 

Functionality: 

Print 

The IFOTA shall allow the user to suppress printing SMART input 
screens 

288 

Functionality: 

Print 

The IFOTA shall allow the user to suppress printing SMART results 

289 

Functionality: 

Print 

The IFOTA shall allow the user to print the scenario summary 

290 

Functionality: 

Print 

The IFOTA shall allow the user to print single/multiple page(s) 
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291 

Functionality: 

General 

The IFOTA shall allow cut, copy, and paste between fields, screens, 
windows and programs 

292 

Functionality: 

General 

The IFOTA shall allow unlimited undo/redo for all text entries 

293 

Module: Help 
System 

The IFOTA shall provide contextual help 

294 

Module: Help 
System 

The IFOTA shall provide a preliminary glossary that the instructor can 
add to at any time. 

295 

Module: Help 
System 

The IFOTA shall display software version and PM/Developer contact 
information under Help:About IFOTA 

296 

Functionality: 

General 

The IFOTA shall display descriptive titles on all windows and dialog 
boxes 

297 

Functionality: 

Navigation 

The IFOTA shall permit the user to open, manage, and work in multiple 
windows 

298 

System: 

General 

The IFOTA shall permit the user to open multiple scenarios 
simultaneously 

299 

Software: 

General 

The IFOTA shall allow the user to open multiple modules in multiple 
windows 

300 

Software: 

General 

The IFOTA shall allow the user to open multiple screens of the same 
module 

301 

Software: 

General 

The IFOTA shall allow the user to open old scenarios concurrent with 
new scenario 

302 

Functionality: 

Navigation 

The IFOTA shall allow the user to navigate through screens in a 
maximum of 5 steps 

303 

Module: Help 
System 

The IFOTA shall use terminology that meets 39th IOS approval 

304 

Module: Help 
System 

The IFOTA shall use procedures that meet 39th IOS approval 

305 

Software: 

General 

The IFOTA shall identify and keep track of where each planner is within 
the 5 operational phases 

306 

Software: 

General 

The IFOTA shall identify and keep track of where each planner is within 
the 72-hour planning cycle 

307 

Software: 

General 

The IFOTA shall display plans across operational phases and planning 
cycles 
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308 

Software: 

General 

The IFOTA shall accept and maintain integrity of task branches 

309 

Software: 

General 

The IFOTA shall have a summary screen for each module 

310 

Module: 

Deconfliction 

The IFOTA shall have a deconfliction/coordination function 

311 

Software: 

General 

The IFOTA shall recognize workgroup members 

312 

Software: 

General 

The IFOTA shall allow workgroup members to view each others' work 

313 

Functionality: 

Chat 

The IFOTA shall allow chat-style communication between workgroup 
members 

314 

Functionality: 

Chat 

The IFOTA shall capture chat communication between workgroup 
members 

315 

Software: 

General 

The IFOTA shall allow students to enter their own decision selections 

316 

System: 

General 

The IFOTA shall provide graceful degradation 

317 

System: 

General 

The IFOTA shall be designed to be extensible 

318 

Functionality: 

Print 

The system shall provide a print-preview function. 

319 

Functionality: 

General 

The system shall allow the user to save a scenario as a new name, at 
any point. 

320 

Functionality: 

General 

The system shall allow the user to save their scenario and continue 
working on it. 

321 

Functionality: 

General 

The IFOTA shall prompt the student to login (appropriate permissions will 
be keyed to login) 

322 

Functionality: 

General 

The IFOTA shall identify types of users and work group members 
through coded logins 

323 

System: 

General 

The IFOTA shall prompt the student to select a module in the login 
screen 

324 

System: 

General 

The IFOTA shall use login information to direct file save paths 


A-20 

Approved for public release; distribution unlimited. 




325 

System: 

General 

The IFOTA shall provide scenario search capability on a single screen 
through a clickable world map and a text-based search function 

326 

System: 

General 

The IFOTA shall provide a geographically-based scenario search 
capability through a MAJCOM map that permits the user to drill down to 
specific countries and local areas to obtain the scenario files for the 
chosen area. 

327 

System: 

General 

The IFOTA shall provide a text search capability that permits the user to 
obtain the scenarios for specific ethnocultural groups, tactical tasks, 
discipline-specific tasks, or geographic locales 

328 

System: 

General 

The IFOTA shall prompt the scenario creator/modifier to tag the scenario 
by geographic locale, ethnocultural group, and tactical/support tasks 

329 

System: 

General 

The IFOTA shall permit the scenario to be opened from the scenario 
search results display 

330 

Software: 

General 

The IFOTA shall provide access to all functions through a menu bar with 
main menus and submenus 

331 

Software: 

General 

The IFOTA shall display keystroke combination shortcuts for actions on 
the submenus 

332 

Module: Help 
System 

The IFOTA shall identify icon function with hovertext 

333 

Software: 

General 

The IFOTA shall provide alternate access to frequently used functions 
through a tool bar 

334 

System: 

General 

The IFOTA shall be able to be installed and run on a JWICS system 

335 

Module: Help 
System 

The IFOTA shall provide a Help function 

336 

System: 

General 

The IFOTA shall have PSYOP, MD, OPSEC, and PA modules 

337 

System: 

General 

The IFOTA shall include a Cl module 

338 

System: 

General 

The IFOTA shall have a module that accepts/displays EW and NW 
planning entries 

339 

Module: 

Instructor 

The IFOTA shall have an Instructor module 

340 

Module: RFI 

The IFOTA shall provide an RFI management function 

341 

System: 

General 

The IFOTA shall be designed to facilitate integration with IOPC-J 
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342 

Software: 

General 

The system shall support a mult-user environment. 

343 

Software: 

General 

The system shall support an individual user environment. 

344 

Software: 

General 

The system shall support a concurrent user environment. 

345 

Software: 

General 

The IFOTA shall have a graceful shutdown process. 

346 

Software: 

General 

Entrance into the IFOTA software shall be gained by double-clicking on 
an IFOTA icon. 

347 

Software: 

General 

The initial IFOTA screen shall display a splash screen. 

348 

Software: 

General 

The IFOTA shall have an autosave function. 

349 

Software: 

General 

The IFOTA shall provide meaningful error messages with instructions. 

350 

Software: 

General 

The IFOTA shall permit simultaneous access by multiple users to one 
scenario. 

351 

Software: 

General 

The IFOTA shall have a login feature. 

352 

Software: 

General 

The IFOTA shall have a 'student' permissions level. 

353 

Software: 

General 

The IFOTA shall have an 'instructor' permissions level. 

354 

Software: 

General 

The IFOTA shall have an 'admin' permissions level. 

355 

Software: 

General 

The IFOTA shall allow the user to save his work in a directory specified 
by the user. 

356 

Software: 

General 

The IFOTA shall be platform independent. 

357 

Software: 

General 

The IFOTA shall provide a backup feature. 

358 

Functionality: 

Print 

The system shall have a print function. 
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359 

System: 

General 

The system shall allow the user to generate a new scenario. 

360 

System: 

General 

The system shall allow the user to open existing scenarios. 

361 

System: 

General 

The sytem shall have a spell check feature for all user-entered text 
boxes. 

362 

System: 

General 

The system shall allow the user an unlimited number of login attempts 

363 

System: 

General 

The IFOTA shall be fully functional for one user only. 

364 

System: 

General 

The IFOTA shall be fully functional for a team of users, each working on 
different modules. 

365 

Module: RFI 

IFOTA shall provide a Request for Information (RFI) module. 

366 

System: 

General 

IFOTA shall permit users to access multiple scenarios simultaneously 

367 

System: 

General 

IFOTA shall display a summary of the justification text entered. May be 
the same screen it was entered in. 

368 

System: 

General 

IFOTA shall display a summary of the deconfliction text entered. May be 
the same screen it was entered in. 

369 

System: 

General 

IFOTA shall capture plan sequels 

370 

System: 

General 

IFOTA shall use the FM 3-05.301 as a guide to developing the PSYOP 
planning module. 

371 

System: 

General 

IFOTA shall provide a means to capture Target Audience Analysis 
planning (ref. FM 3-05.301) 

372 

System: 

General 

IFOTA shall use the USAF Operational Military Deception Planners 
Handbook as a guide to developing the MD planning module. 

373 

Software: 

General 

The IFOTA shall provide an example list of Air Force operational 
objectives organized by service supported 

374 

Functionality: 

Print 

The IFOTA shall allow users to print MD, PSYOP, OPSEC and/or PA 
plan summaries contained within a scenario 

375 

Functionality: 

Print 

The IFOTA shall allow users to print complete set of MD, PSYOP, 

OPSEC and/or PA supporting tasks (with associated decision criteria) 
contained within a scenario (complete 10 discipline plan) 
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376 

Functionality: 

Print 

The IFOTA shall allow users to print MD, PSYOP, OPSEC and/or PA 

COAs (with associated decision criteria) for individual tactical tasks 
(portions of the 10 discipline plan) 

377 

Functionality: 

Print 

The IFOTA shall allow users to inputs to the Commander's Briefing 

378 

Functionality: 

Print 

The IFOTA shall allow users to print the Commander's Briefing 

379 

Functionality: 

Print 

The IFOTA shall allow users to print the target list 

380 

Functionality: 

Print 

The IFOTA shall allow users to print the event schedule 

381 

Software: 

General 

The IFOTA shall capture user-identified high priority targets 

382 

Software: 

General 

The IFOTA shall capture user-identified high payoff targets 

383 

Software: 

General 

The IFOTA shall capture user-identified common targets 

384 

Software: 

General 

The IFOTA shall capture user-identified prioritization for the combined 10 
COA recommendations in the Commander's Briefing 

385 

Module: MD 

The IFOTA shall capture user-generated probability of success estimates 
for MD supporting tasks 

386 

Module: 

PSYOP 

The IFOTA shall capture user-generated probability of success estimates 
for PSYOP supporting tasks 

387 

Module: 

OPSEC 

The IFOTA shall capture user-generated probability of success estimates 
for OPSEC supporting tasks 

388 

Module: PA 

The IFOTA shall capture user-generated probability of success estimates 
for PA supporting tasks 

389 

Module: MD 

The IFOTA shall capture user-generated rankings for MD supporting 
tasks 

390 

Module: 

PSYOP 

The IFOTA shall capture user-generated rankings for PSYOP supporting 
tasks 

391 

Module: 

OPSEC 

The IFOTA shall capture user-generated rankings for OPSEC supporting 
tasks 

392 

Module: PA 

The IFOTA shall capture user-generated rankings for PA supporting 
tasks 
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393 

Module: MD 

The IFOTA shall capture user-identified MD supporting tasks and include 
in them in the Commander's Briefing 

394 

Module: 

PSYOP 

The IFOTA shall capture user-identified PSYOP supporting tasks and 
include in them in the Commander's Briefing 

395 

Module: 

OPSEC 

The IFOTA shall capture user-identified OPSEC supporting tasks and 
include in them in the Commander's Briefing 

396 

Module: PA 

The IFOTA shall capture user-identified PA supporting tasks and include 
in them in the Commander's Briefing 

397 

Module: MD 

The IFOTA shall capture user-identified justifications for MD supporting 
tasks in the Commander's Briefing 

398 

Module: 

PSYOP 

The IFOTA shall capture user-identified justifications for PSYOP 
supporting tasks in the Commander's Briefing 

399 

Module: 

OPSEC 

The IFOTA shall capture user-identified justifications for OPSEC 
supporting tasks in the Commander's Briefing 

400 

Module: PA 

The IFOTA shall capture user-identified justifications for PA supporting 
tasks in the Commander's Briefing 

401 

Module: MD 

The IFOTA shall capture user-provided cost/benefit assessment or other 
cost-based assessment or cost documentation for each MD supporting 
task 

402 

Module: 

PSYOP 

The IFOTA shall capture user-provided cost/benefit assessment or other 
cost-based assessment or cost documentation for each PSYOP 
supporting task 

403 

Module: PA 

The IFOTA shall capture user-provided cost/benefit assessment or other 
cost-based assessment or cost documentation for each PA supporting 
task 

404 

Module: MD 

The IFOTA shall capture user-identified cost information for MD 
supporting tasks in the Commander's Briefing 

405 

Module: 

PSYOP 

The IFOTA shall capture user-identified cost information for PSYOP 
supporting tasks in the Commander's Briefing 

406 

Module: 

OPSEC 

The IFOTA shall capture user-identified cost information for OPSEC 
supporting tasks in the Commander's Briefing 

407 

Module: PA 

The IFOTA shall capture user-identified cost information for PA 
supporting tasks in the Commander's Briefing 

408 

Module: MD 

The IFOTA system shall capture user justification for MD support task 
and associated MOE/MOP recommendations 

409 

Module: MD 

The IFOTA system shall capture user justification for MD story 
development 
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410 

Module: MD 

The IFOTA system shall capture user justification for MD story delivery 
means 

411 

Module: MD 

The IFOTA system shall capture user justification for MD Event Schedule 
entries 

412 

Module: MD 

The IFOTA system shall capture the user's target audience analysis 

413 

Module: MD 

The IFOTA shall provide space for the user to insert measures of 
effectiveness (MOEs) for each MD supporting task (aka MD tactical 
supporting task) 

414 

Module: MD 

The IFOTA shall provide example MD MOEs 

415 

Module: MD 

The IFOTA shall allow the user to input MD means 

416 

Module: MD 

The IFOTA shall allow the user to select multiple MD means 

417 

Module: 

PSYOP 

The IFOTA shall link to PSYOP supporting references (simulating 
reachback and SIPRNET) 

418 

Module: 

PSYOP 

The IFOTA system shall capture the user's PSYOP target audience 
analysis 

419 

Module: 

PSYOP 

The IFOTA system shall capture the user's likelihood of change estimate 

420 

Module: 

PSYOP 

The IFOTA system shall capture a description of the user-developed 
influence COA 

421 

Module: 

PSYOP 

The IFOTA system shall capture the user's scheduling/timing 
recommendations 

422 

Module: 

PSYOP 

The IFOTA system shall display the PSYOP schedule of events 

423 

Module: 

PSYOP 

The IFOTA system shall capture operational feedback (simulated mission 
results) 

424 

Module: 

PSYOP 

The IFOTA system shall display operational feedback 

425 

Module: 

PSYOP 

The IFOTA system shall distinguish between MOE and MOP feedback 

426 

Module: 

PSYOP 

The IFOTA system shall capture user justification for target action and 
MOE/MOP selection 
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427 

Module: 

PSYOP 

The IFOTA system shall capture user justification for selection of best 
changes to influence factors 

428 

Module: 

PSYOP 

The IFOTA system shall capture user justification for influence COA 
development 

429 

Module: 

PSYOP 

The IFOTA system shall capture user justification for delivery method 
and time inputs 

430 

Module: PA 

The IFOTA system shall permit the user to capture MOEs for PA-specific 
tactical support tasks 

431 

Module: PA 

The IFOTA system shall capture user justification for MOEs and MOPs 

432 

Module: PA 

The IFOTA system shall capture the PA desired target opinion 

433 

Module: PA 

The IFOTA system shall capture the PA "worst case scenario" 
assessment and associated requirements 

434 

Module: PA 

The IFOTA system shall capture the user's PA target audience analysis 

435 

Module: PA 

The IFOTA system shall capture operational feedback (simulated mission 
results) 

436 

Module: PA 

The IFOTA system shall display operational feedback 

437 

Module: PA 

The IFOTA system shall distinguish between MOE and MOP feedback 

438 

Module: 

OPSEC 

The IFOTA system shall capture the OPSEC target audience analysis 

439 

Module: 

OPSEC 

The IFOTA system shall capture operational feedback (simulated mission 
results) 

440 

Module: 

OPSEC 

The IFOTA system shall display operational feedback 

441 

Module: 

OPSEC 

The IFOTA system shall distinguish between MOE and MOP feedback 

442 

Module: 

OPSEC 

The IFOTA system shall capture user justification for MOEs and MOPs 

443 

Module: 

OPSEC 

The IFOTA system shall capture impact in the range of 1-100. 
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APPENDIX B 

USE CASES & UML DOCUMENTATION 
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Figures B-l through B-4 illustrate UML modeling for IFOTA. 
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Figure B -1. Truncated Entity-Relationship Diagram (based on Version 2) 
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Figure B - 2. General Class Diagram of Main Planning Elements (based on Version 2) 
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Figure B - 3. Use Case Diagram (based on Version 2) 


Figure B - 4. View Model Class Diagram (based on Version 2 - Jung) 
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MEMORANDUM FOR RECORD 

SUBJECT: IWE DO-0008 Trip to Hurlburt Field, FL (39 th IOS Schoolhouse) 

FROM: Elisabeth Fitzhugh, Human Factors Fead, SRA International 

1. Introduction. Notes below are captured in terms of utility and usability issues and 
requirements identified during the trip. 

IOTA, a Psychological Operations (PSYOP)-oriented planning tool, is intended to be an 
influence operations training aid that walks analysts through the PS YOP planning process 
and prompts analysts to evaluate potential courses of action. It uses standardized military 
objectives based on tenets of air and space employment. COA evaluations are based on 
1) subjective weights and ranks assigned to critical cultural factors associated with the 
target audience (TA) that impact achieving the desired effect and 2) the anticipated 
probability of modifying those factors to induce the desired effect. The evaluation is a 
risk assessment for the projected course of action (COA). 

The current version was developed for operational use. Future plans call for updating the 
PYSOP component and integrating Military Deception (MD), Public Affairs (PA), and 
Operations Security (OPSEC) planning components using the same or similar algorithms 
to assess COAs. 

The trainers’ goal is for the system to support student acquisition of an integrated 
multidisciplinary perspective capability as well as specific AOC targeting and planning 
capabilities. IOTA should support students as they learn to organize a body of 
knowledge, plan and execute a strategy across ah influence operations disciplines. 

AF Influence Operations (10) are based on exploitation of the adversary’s mental state. 
The choice between media-based and leaflet-based campaigns or other non-kinetic 
methods are choices between delivery mechanisms. In determining methods, students 
must bear in mind where information comes from and its probable validity, maintain an 
appropriate cultural mindset, understand the “why” behind the information, and form 
appropriate mental models. They must be able to weight TA fears, understand how those 
fears influence behavior, and understand the “why” behind behavior. 

2. Usability Issues (Focus on the User) 

User Characteristics 

2. Class Demographics: 

a. Joint class members are integrated by service and rank (range from E-2, 
E3 to Ft Col). Members exhibit differential levels of expertise; levels 
of expertise range from 2 to 3 years (beginner) to 15 years (expert). 

Issue : Class tools need to be scalable to teach and test multiple levels of 
expertise. 

b. There are one to two instructors per ~20-person Influence Operations 
(10) class. The class focuses on Falconer Aerospace Operations Centers 
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(AOCs). Class population comes from the nine Information Warfare 
Flights (IWFs) Class constitution is governed by the gaining unit and 
their needs. Percentages change from class to class. 

Issue : Student need for instructor attention will vary. Class tools need to be 
self-supporting to some degree to allow students to work independently, 
c. Students are taught how to support all 10 disciplines used in AOC but 
when they report to their IWFs, they will fill whatever slots are open, 
performing IPB for deliberate planning and continuous update functions. 
During contingencies, approximately Vi the flight will go with the AOC; 
the rest will remain with the IWF, supplying reachback. 

Issue : There is a concern that students may forget lessons that aren’t 
reinforced over time. 

3. Student Computer Expertise: 

a. The tool is HTML-based and will be accessed as a web page. The web 
page interface is desirable as all students should have familiarity with a 
web environment; students are expected to know how to use typical 
internet browser functions. 

Issue : The tool needs to incorporate all the capabilities of a web 
environment ( highlight, copy, paste, save as). Aids should include pop ups, 
hover, find, and drill down capabilities. Users should be able to jump to 
mail to output to other organizations. 

b. Student briefings, which simulate presentations to AOC decision 
makers, are done in PowerPoint (however, trainers express a desire for 
the system to integrate with all MS Office). 

Issue : The tool currently supports copy and paste functions, but automating 
transfer of information from the tool to the PowerPoint presentation would 
save time and effort. Trainers want the program to integrate with Microsoft 
Office and be able to “push” to TBMCS. 

Task Characteristics 

2. Task Overview: 

a. Tasks are constrained by class time. In the first part of the course, 
trainers give an overview of the different disciplines, the standard 
measures of behavior, and how to measure behavior. In the second 
phase, SMEs give units of instruction on their specific disciplines, use 
slides accompanied by slide notes. The course moves from rote memory 
exercises to demonstrations of subject matter expertise. 

Issue : Currently, students get three weeks of practice in the planning stage. 
Eventually, trainers will integrate practice exercises into more of the course. 
Instructors and students will create new scenarios to add to IOTA’s existing 
scenario database. As more information is acquired, there will be a need to 
update the influence operations factors to reflect increased understanding. 

b. Using the tool prototype, for a given scenario, students should be able to 
identify operational and tactical objectives and associated measures of 
effectiveness (MOEs), characterize the target audience and identify 
opportunities, limiting factors (LIMFACs) and susceptibilities, and rank 
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and weight the susceptibilities. The students should be able to give a 
level of confidence in information and a level of effectiveness (ability to 
reach the susceptibility); the student should be able to weight the 
likelihood of success. 

Issue : Students will have access to Secure Internet Protocol Router Network 
(SIPRNET), Non-Secure Internet Protocol Router Network (NIPRNET), 
and the Joint Worldwide Intelligence Communications System (JWICS). 

The user must be able integrate database access and exercise activities. The 
students use IWPC, IWS, and ION; some degree of IOTA integration may 
be required. 

c. To complete the task, students should be able to use available databases 
to research culture and leadership aspects to determine how to affect the 
population and the leadership. 

Issue : Navigation between planning and decision support tools and 
supporting databases should require minimal effort and minimal time. No 
picture of what the screen will look like while the student moves between 
application and reachback capabilities is currently articulated. How the 
system looks, how the students will keep track of where they are between 
applications, how quickly and easily they can navigate and how quickly and 
easily the database supports their information quests are all human factors 
integration issues. 

GUI Environment 

2. Common Look and Feel: 

b. The IOTA tool, like some other applications students will use, is web- 
based. Other applications are MS Office-based or employ the standard 
Windows work environment. 

Issue : The IOTA tool GUI should leverage student familiarity with the MS 
Internet Explorer web browser and Office suite GUIs. It should also 
leverage all Windows “Help” capabilities and user aids (Help topics. Table 
of Contents, Index, Glossary, context-sensitive Help, etc.) 

Operational Environment 

2. Environmental Characteristics: 

b. Students will be working as teams to create their recommendations. 

Students will represent the different disciplines/roles found in the AOC. 
Issue : Students need to be able to work alone or collaboratively. Students 
need to be able to deconflict their respective plans. 

3. Utility Issues (Focus on the Task) 

Job Requirements 

2. Mission-level Expectations: 

a. Students will be taking the role of AOC staff and will have to consider how 
their input factors into the overall mission plan 
Issue : None currently identified 
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b. Expectations are that students will push to have the training tool made 
operational. 

Issue'. The more realistic the training tool is, the more likely students are to 
push for it; a very realistic training tool will be easier to operationalize. 

c. The students must integrate and deconflict their recommendations with other 
10 disciplines 

Issue: A vision of how the deconfliction aspect will work has not yet been 
articulated. 

Trainer Tool Use 

4. Tracking: 

a. Trainers have not yet considered all they want the tool to track. They 

exhibited a positive response to the suggestion that the tool might include a 
mechanism for tracking exercise and test performance. System tracking 
would lighten the trainer workload. 

Issue: Any tracking expectations should be worked out now to aid the 
designers’ planning process. Trainers indicate they will be giving individual 
grades and group grades for group efforts. How to track that should be thought 
out in advance as well. 

5. Testing: 

a. Trainers expect to use the tool in both in class exercises (partial tasks) and 
the capstone exercise that will permit students to integrate all they have 
learned in the course. 

Issue: Trainers indicated a desire to be able to see what students were doing in 
order to supervise and aid. 

b. Trainers want to integrate students’ capabilities in team exercises and stretch 
everyone. They want to elicit thinking through student identification of 
options and variables. Trainers suggest that the tool include an option that 
allows them to increase exercise difficulty based on student performance 
(“teach to each” versus “teach to mean”). An example is the ability to go 
from a two-channel “on/off’ scenario to a five-channel one, increasing the 
number of options in the variables offered. They also suggest adding an 
assessment method to tell what would have happened if the student had 
chosen differently, following the branches, and a method to anticipate 
sequels. 

Issue: Currently there is no scalability in the training module. Specific 
requirements for extension modules are yet to be determined. 

6. Feedback: 

a. Subjective weightings/rankings are only as good as the student’s expertise 
and information base. The exercise of decomposing the factors that affect 
the TA and watching how changing weights for individual factors changes 
the probability of success is valuable in itself. Trainers suggested that they 
would like to see feedback. They envisioned the following training 
scenario: 
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• For a given exercise, the system provides a series of variables that 
form three distinct paths to follow (Path A=50% of the solution, 
Path B=100%, and Path C=25%). 

• System collects data on the students’ selection of variables and 
how they justified them. 

• System identifies the incorrect paths and the shows cascading 
effects from following the wrong route. 

• System shows the correct path and its cascade of effects. 

• Trainer tracks student progress; if at any point, the student chooses 
A, the trainer can show why that path is not optimal, but if the 
student chooses C, the trainer knows to take him/her back to 
basics. 

Issue: Hardwiring, as described above, cuts down on options, but the trainers 
say that is all right for a training aid. Providing only this option would not 
necessarily provide a close match with reality, where there is often no right 
answer. 

b. However, the system could also be designed to allow freedom of 

thought/movement, offering a best choice answer and several others that 
varied in degree of usefulness, and allowing the student to work out a best 
possible solution. In this mode, the system again would show possible 
outcomes. 

Issue: Including both of these modes would allow the student to progress from 
canned classroom scenarios to real world scenarios. It would also provide a 
method for providing increased difficulty for more able students. 

Student Tool Use 
3. Student Task: 

a. The classes mirror every step of the planning process, taking the student 
from “hands-on” trainer-supported exercises to a “hands-off’ capstone 
training effort. Trainers provide the students with a set of JTF objectives 
and plug in standardized objectives for the exercise, depending on the 
scenario (e.g., eight objectives for phase one). Influence operations 
objectives will be the sub-objectives (influence nation command, influence 
political structure, etc.) Each individual discipline can answer the need. 
Students learn to write their own objectives and how to modify Air Staff 
concepts to perception management needs and integrate counter-intelligence 
perspectives. Students must learn to support why a non-kinetic option is 
preferable to convince the AOC. They must be able to present their plan, 
provide appropriate details, make a strong argument, show the effects and 
the effects desirability, and defend the plan’s solution. 

Issue: IOTA must be updated to include the entire planning process; the 
designers intend for the tool to mirror the language used in AOC planning. As 
the AOC planning process is under development, language changes may have to 
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be updated/updatable. (MOEs should be included in the program, but need to 
be adjustable as analysis renders them inappropriate.) 

b. In the new exercises, all targets go “on deck” no matter how they are to be 
prosecuted, only the restricted target list will be retained. Kinetic and non- 
kinetic options will be de-conflicted (e.g., will ensure that there is no close 
air support activity scheduled for the vicinity of leaflet drops). The point is 
to integrate the air picture for the day and deconflict all missions at once. 

Issue : How the deconfliction aspect will be managed is not yet articulated. 

c. Students will practice assuming different roles in the AOC. Hands-on 
exercises will be require both individual effort, with each student using 
different expertise to do his/her own portion, and group coordination, 
integrating and deconflicting individual efforts. Lesson includes teaching 
students how to present to staff estimates of non-kinetic actions. In order to 
accomplish the task, students also must learn how to manage group 
dynamics. 

Issue : How the students will collaborate is not yet articulated. 

4. Task Support: 

a. Classification: At IOIC, students will stay on JWICS, with SIPRNET and 
NIPRNET for research and reach-back capabilities. MD will be done at the 
SECRET/NOFORN level, and will incorporate national level entities on 
JWICS. Exercises may require going to a high level classification. 

Issue: Unclassified paradigms for scenarios will need to be built; there will be 
nothing classified in the developmental design. For the MD section, the design 
will need to separate high and low classification aspects (multi-level security?). 

b. MD, OPSEC and PSYOP employ somewhat different terminologies to 
reflect their different perspectives. OPSEC is the only track that asks the 
student to look at how their plan will both impact US activities (giving 
Indications and Warnings; I&W) and US perceptions. 

Issue: Language usage will have to be carefully documented and managed. 
Additionally, the OPSEC track may pose difficulties for students as they have to 
focus their objectives differently than in PSYOP and MD. The OPSEC 
objective is to remove I&W, whereas the MD objective is to exploit them. 

c. How well the students know where to get data will vary by student; students 
are given lists of urls in class that the instructors have compiled. 

Issue: The instructor-supplied urls can be integrated into the internet browser as 
favorites and the file emailed for importation in the students’ home systems. 

d. Students must factor in cultural analysis issues (e.g., how to communicate 
with non-literate populations). Students are taught to leverage preconceived 
adversarial and military mindsets. 

Issue: PYSOP recommendations are turned over to the Army for 
implementation. The actual method of implementation is not determined by the 
student. 
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e. In the current version of the tool, the focus is on the factors that influence 
TA behavior, the estimated difficulty friendly forces will experience 
directing TA behavior toward the goal state. 

Issue : The goal state is represented by standard PSYOP objectives; the actual 
PSYOP plan is not captured when users project probability of success 
influencing TA behavior. 

f. PSYOP doctrine is in a state of flux. The new JP 2.5.3 draft hasn’t been 
signed yet; neither has the new OPSEC draft. 

Issue: The changes in doctrine will probably impact lesson plans and decision 
support tool requirements. Additionally, according to the trainers, current AF 
training focuses on deliberate and contingency planning for force execution 
missions. Training doesn’t cover how to plan for Humanitarian Assistance 
(HA), Noncombatant Evacuation Operations (NEO), and Civil Affairs (CA) 
outside of hotspots in the Middle East. Training doesn’t cover planning for 
nation building or planning for handing over an area to the ambassador for 
reconstruction. Training doesn’t cover how to redeploy, reconstitute or employ 
forces in interim periods and how to get people in and out safely. PSYOP is 
concerned with developing ways to endear US forces to the population to 
reduce risk and increase cooperation. Any future effort to add in these training 
modules will extend required scenarios considerably. 

4. System Requirements 

1. Modify current version to show military objectives at three levels: 

• Operational air objectives 

• Tactical objectives 

• Tactical tasks 

2. Modify current version to include success indicators (measures of merit) at each 
level of objective. 

3. Modify current version to allow the operator to modify operational objectives, 
sub-objectives and success indicators. 

4. Update current version to reflect new PSYOP-related behavioral information. 

5. Modify current version to reflect language used in course/work area. 

6. Integrate the work domain language of all SME tracks into the tool. 

7. Develop a glossary for planning language. 

8. Develop interoperability with Sensor Harvest, IWPC, IWS, ION 

9. Redesign current tool to take the trainee from planning to outbrief. Modify the 
current tool to export the objectives, measures of merit, suggested COAs (in rank 
order), COA risk assessment/rationales, and anticipated end states to a 
PowerPoint slide show suitable for briefing decision makers. 

10. Include a capability to track student progress, give feedback, show alternative 
paths and outcomes, and capture student performance. 

11. Include a capability to show branches and sequels for planning over time. 

12. Include a capability to update scenarios based on target audience response. 

13. Integrate the tool with MD (uses MIDB) and OPSEC data sources and planning 
tools. (Currently, PA has only been discussed as an adjunct to each of the other 
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disciplines.) Integration should include deconfliction of PSYOP, MD and OPSEC 
COAs. 

14. Integrate the tool with Secure Internet Protocol Router Network (SIPRNET), 
Non-Secure Internet Protocol Router Network (NIPRNET), and the Joint 
Worldwide Intelligence Communications System (JWICS) 

15. Develop ability to capture information in different databases and integrate access 
to database system. In PSYOP and MD, need to be able to populate the databases 
with new information as it is learned. 

5. Collection/Testing Suggestions 

1. Need to perform cognitive walk-throughs with several trainers (optimally, with 
students, too) to observe and analyze tool use behaviors. 

2. Need to perform experiments to differentiate between “aided” versus “unaided” 
performance. Need to collect baseline performance data. 

3. Need to perform usability tests (includes collection of error behaviors, system 
response to errors, hesitations, system aid needs, performance times, etc.) 

6. MD & OPSEC 

• The MD and OPSEC processes model the basic 10 process; some terminology 
differences were noted and will have to be incorporated in design planning. 

• 10 (especially in MD) identifies the primary decision maker and leverages 
his/her perceptions to US advantage. Whenever possible, it seeks the path of 
least resistance, using adversary opinion rather than changing it. 

• MD’s twin goals are to increase adversary ambiguity to slow correct decision 
making, and conversely, to decrease adversary ambiguity to speed incorrect 
decision making. OPSEC goals are to maximize our information protection 
and minimize our information leaks. In contrast, MD leverages information 
leaks. 

• Trainers indicate MD and OPSEC options can be broken out as variables and 
weighted as is done for PSYOP in IOTA. The trainers anticipate the IOTA 
algorithms will work with minimal adjustment. The OPSEC focus is internal. 
It includes internally-directed vulnerability assessment and situational risk 
assessment elements that must be factored into its track design. 

• MD and OPSEC use PA extensively and ideally are never isolated from PA 
planning. However, no PA representative was available to discuss PA track 
requirements. 

• Although the major emphasis was on deconfliction of different tracks; trainers 
also mentioned cooperative efforts across tracks. In the future, cooperative 
planning capabilities may have to be added to IOTA. 

• MD and OPSEC requirements were in synchrony with PSYOP requirements. 
With the exception of PSYOP-specific comments, system requirements can be 
assumed to apply to MD and OPSEC tracks. 
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MEMORANDUM FOR RECORD 

SUBJECT: IWE DO-0008 Trip to Hurlburt Field, FL (39 th IOS Schoolhouse) 
FROM: Mike Zywien, Project Lead, SRA International 


3. Notes below are captured in terms of the “usability” and “usefulness” criteria SRA is 
developing for the IOTA project. 

4. Usefulness Criteria (How effective and flexible is IOTA in supporting the work of the 
10 instructor and student?): 

a. Effectiveness 

i. Support 10 planning for all phases of an OPFAN 

ii. Ensure Objectives get entered in correct terminology and structure and 
can have associated success indicators and measures of merit inserted 

iii. Account for uniqueness of each track (e.g. MD process and target 
distinctions from PSYOP process/targets, OPSEC process/targets) 

iv. Take advantage of synergies among tracks 

v. Account for risk as well as probability of success in presentation of 
output 

vi. Ensure each module (PA, MD, PSYOP, OPSEC) reflects the process 
for that track (not all processes are the same) 

vii. Does IOTA ontology/taxonomy mirror the language of the course 
materials and the relevant discipline 

viii. Does IOTA reinforce the instructors presentation of the course work 

1. IOTA presentation mirrors 10 planning process taught in 
lessons 

2. IOTA provides cues/prompts when reachback is required 

3. Import methodology and format for reachback simulates 
process taught in lessons 

ix. Does IOTA reinforce student understanding of the course work 

1. IOTA presentation is familiar to student and mirrors process 
taught in lessons 

2. Understanding of when reachback is needed is clear and 
straightforward 

3. Easy cues/prompts to access needed data sources (reachback) 

4. Student can import reachback data as required 

5. Interoperability with other applications - student can provide 
model output in required presentation formats 

x. Scaleability 

1. IOTA can be used for beginning and challenged students and 
advanced students can take advantage of features to push the 
analysis envelope and bring in more expertise and 
sophistication 
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2. Ability to control versions, configuration of tool and data 

xi. Collaboration 

1. Input and results be exchanged, shared 

2. Framework to support collaboration 

3. Internal (within schoolhouse) and external (reachback) 
collaboration 

4. Ensure ability to integrate 10 track (MD, PA, PSYOP, OPSEC) 
plans (build supporting objectives and target assessments) 

5. Ensure ability to de-conflict 10 track plans (flag objectives and 
analyses that will negatively impact plans for other 10 tracks) 

6. Output directly supports presentation of an integrated, de- 
conflicted 10 plan for a given scenario, mission objective 

xii. Extensibility 

1. Students can use this tool when they report to their assigned 
units 

2. IOTA can be implemented in IWPC or Sensor Harvest as a tool 
to support deliberate and crisis action 10 operational planning 

3. Compatibility/extensibility to ION (joint community) 

xiii. Tracking 

1. A way to capture student thought process for each input to the 
model (error traceability, rationale, justification, support for 
end recommendations and outbrief) - notes pages 

2. R/Y/G student grading at completion of model runs with 
appropriate feedback and indications of where errors were 
made, improvements could be made 

3. Guided discovery 

b. Flexibility 

i. Easy to update and expand to advanced versions, new modules, refined 
modules 

ii. Ability to access pre-canned objectives, modify pre-set objectives, add 
new objectives 

5. Usability Criteria (how easy is this tool to use) 

a. Implementation on JWICS (access SIPRNET, NIPRNET source data) 

b. Event and change detection 

c. Representation aiding 

i. Graphical display of “what if’ and impact analysis 

ii. Progress bar to indicate what steps have been successfully 
accomplished 

iii. Buttons to move among track modules (PA, PSYOP, MD, OPSEC) 

iv. Glossary 

d. Error detection and recovery 

i. Help functions - how useful, how comprehensive, how clear and easy 
to use 

ii. Indicators of invalid input (e.g. weights) - “need to re-evaluate” 

iii. Indicators of output that does not make sense 
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e. Make coherent, relevant information out of data 

i. Map IOTA output to what’s needed for target planning presentation 
(e.g. targeting sheet) 

f. Predictive capabilities 

i. “What-if ’ analysis 

ii. Sensitivity analysis 

iii. Impact analysis 

g. Interoperability 

i. Search engine integration (reachback) 

ii. Pointers, aids to access existing data sources 

1. Databases (various organizations) 

2. Web sites (instructor bookmarks) 

3. Documents 

4. Media 

5. SMEs 

iii. “Send to” button for checking, collaboration 

6. Other general observations: 

a. IOS focus is on INTEGRATED 10 Planning at Operational and Tactical 
levels in support of JFC, JFACC campaign objectives 

b. Schoolhouse sends students to all 9 IWFs (USAFE, CENTAF, Davis- 
Monthan, PACAF, USFK, AFSPACE, Weapons School, TRANSCOM, and 
NORTHCOM) 

c. IOTA can support both instruction and testing 

d. Output probabilities may help student adjust measures of merit and Objectives 

e. MD and OPSEC processes are different from PSYOP process, however all 
students will be trained as planners, and all are interested in target 
vulnerabilities and capabilities (targets will be somewhat different for each 
track) 

f. Reachback is very important and needs to be integrated into the IOTA 

g. Sensor Harvest data will be very useful as a reachback capability for IOTA 

h. IWPC is being considered as the “future Joint planning suite.” VPT lessons 
learned may aid IOTA integration into IWPC environment 

i. OPSEC risk assessment methodology may be useful for other tracks, too 

j. OPSEC track can have great potential for conflict with other tracks in that 
other tracks (PA, MD, PSYOP) are interested in exploiting our indicators, 
whereas OPSEC is interested in removing indicators 

7. Plan is to target an interim demonstration of the revised IOTA in the November 2004 
timeframe. This was an extremely valuable collection trip. Team will document 
observations, share them with other participants and the trainers, and use as a basis to 
begin design phase of project. 


MICHAEL L. ZYWIEN 
SRA Project Lead 
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MEMORANDUM FOR RECORD 

SUBJECT: IWE DO-0008 Trip to Hurlburt Field, FL (39 th IOS Schoolhouse) 
FROM: Pat Ryan, Consultant, SRA International 


1. Notes appearing after this page were captured during interviews with Subject Matter 
Experts and System Administration personnel. 


PATRICK H. RYAN 
SRA Project Consultant 
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Notes by Topic 

May 12-13, 2004 

Topic/Role Who 

IOTA 

Metrica 

Metrica 

Metrica 

Metrica 

Metrica 


Comments 


Page 1 of 7 


(Gave PPT presentation on IOTA) 

Intends to create a paradigm that can be copied and 
customized to a specific scenario. 

want to be able to create a scenario for any country, 
(country map (image map?) needs to define region for each 

SMART model accounts for variability in confidence levels 
IOTA is written in C++ 


Metrica 

System Admin (SA 3C) 

System Admin (SA 3C) 

Admin (SA 3C) 

System Admin (SA 3C) 

System Admin (SA 3C) 


Database is current Access. Future version will be SQL 
Server 

Info Workspace (IWS) requires Oracle server. They may be 
installing IWS soon, and if so, they will stand up an Oracle 
server. 

They run Windows2000 on clients, Windows 2000 Server 
on servers. Moving everything to Gigabit Ethernet. Clients 
are Dell slim profile PCs, servers are Compaq Proliant. 
They've got huge budget for equipment so they get pretty 
much anything they want. Micro 

Leah talked to me about their in-house configuration. They 
want to document it in accordance with STEMB (SA 
civilians that do CM for all AF bases), but simply don't have 
time because they are expanding so fast. They use KVM 
switches on all their Dell PC c 

Currently have 7 servers dedicated to single functions: Print 
Server, File server, media server, Veritas backup server, 
web server (Jmeasle, Cold Fusion) 

Would like IOTA to have a nice setup.exe that presents a 
wizard which allows them to choose install directory, drives, 
etc. Central installation would be best (server side vs. 
client side). Their servers located underneath classroom 
seating (amphitheatre 
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May 12-13, 2004 

Topic/Role 


Who 


Comments 


Page 2 of 7 


System Admin (SA 3C) 

They have 5 networks: NSA (going away soon), SIPRNET, 
NIPRNET, JWICS (most robust, where they see IOTA 
installed on) 

System Admin (SA 3C) 

Classes typically 25-60 people at a time. Can 60 use the 
tool at the same time? Multiple classes at the same time? 

IE is the std browser. Prefer not Netscape. Microsoft is 
implied std within 10 School. Training 3C's on how to 
administer IOTA. IIS is their 

System Admin (SA 3C) 

PSYOP Instructor 

Jmeasle simulates an AOC 

The Rendon Group is the subscriptions database that is 
used by 10 Planners. 

PSYOP Instructor 

Tool should mirror every step of planning process 

PSYOP Instructor 

Provide models as a zip file on a web site so it can be 
grabbed before deploying. NASIC does this for one of their 
other tools. Plenty of feedback when updating files (show 
what is new, allow to choose what is updated, etc.). 

PSYOP Instructor 

Col. Durham (sp?) of PA center of excellence (Maxwell AFB) 
could use data from IOTA for their purpose. 

PSYOP Instructor 

Wants to be able to "hand-jam" data into IOTA, (via 
notepad, excel, etc.) Quick and easy way to get data in 

PSYOP Instructor 

Would like to be able to disable options via a tool. (For 
example, vulnerabilities). Selectively hide some of the intel 
data to make the task more difficult. 

PSYOP Instructor 

Capture experts knowledge. NASIC needs to analyze where 
they collect info from and why the info states what it does. 
Flow to pull data from disparate db's into IOTA? 
PSYOPS=''mental state". Flow do 1 get to his "melon". 

What do 1 do to his "melon". Do2= AFI2 

PSYOP Instructor 

For novices (aka "rocks"), the scenarios would get 
progressively easier. For experts, it would get progressively 
harder. 

PSYOP Instructor 

Export to IWPC is the number 1 destination for output of 
IOTA. Excel is backup plan. PowerPoint would also be good 
for briefing JFACC. 

PSYOP Instructor 

Individual grading system required (vice team based) 
because entire team won't deploy together to same area. 
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May 12-13, 2004 

Topic/Role 


Who 

PSYOP Instructor 

PSYOP Instructor 
PSYOP Instructor 


Comments 

PSYOP Instructor talked again about capturing and sharing IOTA data 
with other IOTA users. 

Would like to see wildcard capability in keyword searches 
Need to add MOEs MOPS to the tool. 


PSYOP Instructor 
PSYOP Instructor 

Note 

SRA 

SRA 

SRA 

SRA 

SRA 

SRA 


Wants to edit, add, delete nodes in tool (Objective, Task, MOE, etc.) 
Need to justify the final plan coming out of IOTA: Answer 
the question: "How did I get here?" 


Looks like they might benefit by using Microsoft's TreeView 
in the left pane. Might simplify things a bit. 

IOTA Data Collection. Hurlburt AFB, Ft Walton Beach. 
Information Operations School. Staff Sgt. Spike Szeredy, 
Mike Zywien, Elisabeth Fitzhugh, Pat Ryan, Rosie 
Vasquez (Metrica), Dr. Brice Stone (Metrica), Capt. Tim 
Gameros (AFRL-HE WPAFB), Major Janelle Viera 

All classrooms have 2 plasma display hung in the back of 
the room so the instructor can see what is being displayed 
as well. 1 classroom has about 100 small cubicles with low 
walls so students can see the instructor, but get privacy 
between themselves. 

SRA "Show best changes" link in right pane shows top 3 to 
impact objective. What if it is determined that #2 is not 
feasible given the assets available. Can we see option #4? 
(Provide checkboxes?) 

Is there an editor for adding, modifying, deleting pre-set 
cultural/situational factors that show under each objective? 
(This came up early on in SKOPE development) 

Required fields not obvious until button pressed and 
message window pops up indicating which field was missed. 

Collection and dissemination of data. Taxonomy 
development. Finite/well defined scales for assigning values 
such as weightings, etc. RFIs for DB data? 
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Topic/Role Who Comments 

SME 


PSYOP Instructor 
PSYOP Instructor 
PSYOP Instructor 
PSYOP Instructor 

PSYOP Instructor 

PSYOP Instructor 
PSYOP Instructor 

PSYOP Instructor 

PSYOP Instructor 


New curriculum being developed. Feels IOTA will fit In well. 
Students come up with COAs 
PM=Propaganda management 

SIPRNET and NIPRNET used for research. JWICS will be 
used for IOTA. 

The justification column (in Excel) contains why, what other 
targets are required in conjunction with this one 

JTF objectives given to students 

All objectives should be broad enough to allow any of the 
disciplines to be worked. 

Complexity levels of scenarios. As students get better, 
scenarios should get more complex, answers become more 
ambiguous, giving student more flexibility in analysis (not 
hard wired) 

Primary and secondary objectives provided to students. 


PSYOP Instructor 
PSYOP Instructor 
PSYOP Instructor 
PSYOP Instructor 

PSYOP Instructor 

PSYOP Instructor 


Students are taught to justify PSYOP target 
recommendations 

PSYOP Instructor currently selects zip files representing scenarios and 
expands them to set up for a class 

IOS class course content: Parti: Objectives, samples of 
behavior. Part2: Details of Objectives. 

Air Force has a 1 page doc which describes competence 

levels for students (2B, 3C, etc. where D=Expert). PSYOP Instructor 

will send out in package. We (SRA and Metrica) will tell 

AFRL what docs we want and they will request them from 

Data Weighting: SIGINT report or debrief often gives weighted 
value. Credibility rating given to data entered by a particular 
type of person. Short experience = lower confidence. 

Longer experience = higher confidence. 

Terminal Velocity Exercise: All targets will be put on the 
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Topic/Role 


Who 

PSYOP Instructor 

PSYOP Instructor 
PSYOP Instructor 
PSYOP Instructor 

PSYOP Instructor 

PSYOP Instructor 
PSYOP Instructor 

PSYOP Instructor 
PSYOP Instructor 

PSYOP Instructor 

PSYOP Instructor 
PSYOP Instructor 
PSYOP Instructor 
PSYOP Instructor 

PSYOP Instructor 
PSYOP Instructor 


Comments 

target list, (including PSYOP). That way, leaflet drop won't 
be undermined by a bombing. 

During assessment: best guess applies. In school environment, a right, 
wrong and almost right answers are available to choose from. 

Also need discipline specific objectives (Cl, PM, etc.) 

PSYOP Instructor presented the IWPC PowerPoint presentation. 

IOTA data should be made available from a web site the 
way that Sensor Harvest data is, so that data can be 

Media Mapping Tool=world wide list of subscriptions 
(magazines, newspapers, etc.) 

We teach (????), crisis planning, force execution 

Phase 4 and 5 of a war (aka post-war Iraq) need heavy 
Information Ops planning 

IOS produces students destined for the AOC 

Guidance and Objectives from JFC remain largely 
unchanged through JFACC guidance and objectives. 

Powerpoint presentation briefly describes IW Vis, Tel 
Scope, Esync Matrix, ACE _Team Management - manage 
documents, query them. 

Targeting and Guidance Interface Facility (TGIF) interfaces 
IWPC to TBMCS 

IWPC 4.0 lecture brief should be ready soon. (Weeks?) We 
can request it in our package request (via AFRL) 

IWPC 4.0 going to Operational Task, Tactical Task, etc. 

See PSYOP Instructor's handout 

Priority of targets (GAT) is based on commonality. If the 
Navy and the Army also want the target struck, it is raised 
in priority on the nomination list. Geo location, assets 
available to conduct the attack are also considered. 

IWPC will be a joint tool 

Confusion was shared about entering the 2nd objective. It 
was not clear if it was going to be a sub-objective or what. 

This later turned out to be mostly terminology issue, which 
PSYOP Instructor later resolved for us. Metrica to change. We should 
put screen labels 
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Topic/Role Who 

PSYOP Instructor 

PSYOP Instructor 

PSYOP Instructor 


PSYOP Instructor 

PSYOP Instructor 
PSYOP Instructor 
PSYOP Instructor 


PSYOP Instructor 

SMEMD 

MD Instructor 
MD Instructor 

MD Instructors (2) 
MD Instructors (2) 


MD Instructors (2) 
MD Instructors (2) 


Page 6 of 7 

Comments 

During the GAT meeting (Guidance and Targeting) a 
PowerPoint slideshow of maps showing the targets in 
different colors representing target type (naval, SAM, etc.) is used 

DIA target intel is imported into the MIDB, where it is used 
by 10 Planners using IWPC or Excel, and then it is 
imported into TBMCS 

When viewing the target deck in TBMCS, they found that 
many targets are marked as inactive, simply because they 
don't have recent intel on them. But this doesn't mean they 
aren't a target anymore (absence of evidence is not 
evidence of absence). They get 

For moving targets, BE# of facility they are based out of is 
used. Notes section used to reflect actual current latitude 
and longitude 

Code words are used in the target deck to relate to 
classified targets behind the green door. 

10 Planners spend 50% of their time in the STO (green 
door), and 505 outside 

PSYOP Instructor talked about an AF std worksheet for defining 
objective-task-moe-mop, etc. Said he would send it to us. (I 
gave him my business card, but it might come in the 
package we request via AFRL). 

IWST is now called IWT (??) 


"Spin Control" = PA term for SNOWBALL effect. 

"Consequence Management" = MD term for SNOWBALL 
effect. 

Human Factors database at NASIC is another tool used 

Six stages of MD? (Situation=Military situation you're 
involved in, and what the desired situation is; 
Objective=Military and deception objective; 
Perception=Current enemy perception, desired enemy 
perception; Story=?; means=?, Moe, Mom Mop are the 

Approx 70 core 10 planners were involved in Desert Storm 

Deception has a snowball effect (just like EBO does) 
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Topic/Role 

Who 

Comments 


MD Instructors (2) 

Army deception constrained to their area (5KM x 5KM area 
for example). The point is that they don't look at the big 
picture and how everything is related. 


MD Instructors (2) 

Joint Universal Lessons Learned database is a tool that is 
used 


MD Instructors (2) 

When students leave, they will know how to Plan and 
interact with other Influence Operations 

SME OP SEC 

MD Instructors (2) 

We use reachback to MAJCOMS for advice, help. 


OPSEC Instructor 

OPSEC plays in every objective 


OPSEC Instructor 

3 Questions to ask: Can enemy collect on indicators that 

I've put out there?; Can he analyze it?; Can he act on it?; If 
he can, then what is the impact? 


OPSEC Instructor 

MD enjoys indicators, OPSEC wants to get rid of them 


OPSEC Instructor 

OPSEC Product is OPSEC Annex 


OPSEC Instructor 

Only tool in use is the OPSEC Survey Tool 


OPSEC Instructor 

OPSEC course teaches JOPES, Crisis Action Planning 


OPSEC Instructor 

5 step process 


OPSEC Instructor 

OPSEC guys ensure PA and MD are not revealing anything 
sensitive. 


OPSEC Instructor 

OPSEC monitors our vulnerabilities (not enemy's) 
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APPENDIX E 
ACRONYM LIST 


39 th IOS 

39 th Information Operations Squadron 

711 th HPW 

711 th Human Performance Wing 

ACTA 

Applied Cognitive Task Analysis 

ADV IOIC 

Advanced Information Operations Integration Course 

AFCERT 

Air Force Computer Emergency Response Team 

AFDD 

Air Force Doctrine Document 

AFI 

Air Force Instruction 

AFRL 

Air Force Research Laboratory 

AFTTP 

Air Force Tactics, Techniques & Procedures 

AOC 

Air Operations Center 

BPR 

Business Process Reengineering 

CA 

Civil Affairs 

Cl 

Counterintelligence 

CIA 

Central Intelligence Agency 

COA 

Course of Action 

COM 

Component Object Model 

CSE/SE 

Cognitive Systems Engineering and Software Engineering 

CTA 

Cognitive Task Analysis 

DII COE 

Defense Information Infrastructure Common Operating Environment 

EJB 

Enterprise Java Beans 

EW 

Electronic Warfare 

HA 

Humanitarian Assistance 

HTML 

Hyper Text Markup Language 

I&W 

Indications and Warnings 

IDEFO 

Integrated Definition for Function Modeling 

IFO 

Influence Operations 

IFOTA 

Influence Operations Training Aid 

INOSC 

Integrated Network Operations and Security Center 

INTRO IOIC 

Introductory Information Operations Integration Course 

10 

Information Operations 

ION 

Information Operations Navigator 

IOPC-J 

Information Operations Planning Capability - Joint 

IOTA 

Information Operations Training Aid 

IOTT 

Information Operations Team Training 

IW 

Information Warfare 

I WAS 

Information Warfare Aggressor Squadron 

IWE 

Information Warfare Effectiveness 

IWF 

Information Warfare Flight 

IWPC 

Information Warfare Planning Capability 

IWS 

InfoWorkspace 

JAEP 

Joint Air Estimate Process 
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JAOC 

Joint Air Operations Center 

JAOP 

Joint Air Operations Plan 

JCS 

Joint Chiefs of Staff 

JDBC 

Java Data Base Connectivity 

JFACC 

Joint Force Air Component Commander 

JMS 

Java Messaging System 

JP 

Joint Publication 

JTF 

Joint Task Force 

JWICS 

Joint Worldwide Intelligence Communications System 

FIMFACs 

Limiting Factors 

MAJCOM 

Major Command 

MD 

Military Deception 

MEC 

Mission Essential Competency 

MOE 

Measure of Effectiveness 

MOP 

Measure of Performance 

NEO 

Non-Combatant Evacuation Operations 

NIOC-MD 

Navy Information Operations Command-Maryland 

NIPRNET 

Non-Secure Internet Protocol Router Network 

NOD 

Network Operations Division 

NW 

Net Warfare 

OPSEC 

Operations Security 

OSGI 

Open Systems Gateway Initiative 

PA 

Public Affairs 

POL 

Petroleum, Oil, & Lubricants 

PSYOP 

Psychological Operations 

PSYOPPT 

Psychological Operations Planning Tool 

RCP 

Rich Client Platform 

RFI 

Request for Information 

RHA 

Warfighter Readiness Research Division 

RHC 

Warfighter Interface Division 

RMI 

Remote Method Invocation 

SIPRNET 

Secret Internet Routing Protocol Network 

SMART 

Subject Matter Analysis & Research Toolkit 

SMC 

Signature Management Course 

SME 

Subject Matter Expert 

TA 

Target Audience 

TBMCS 

Theater Battle Management Core Systems 

UML 

Unified Modeling Language 

USA 

United States Army 

USAF 

United States Air Force 

WAET-C 

Warfighter Analysis of Innovative Technologies and Concepts 

WCD 

Work-Centered Design 
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